Opened 6 years ago

Closed 6 years ago

#10562 closed enhancement (fixed)


Reported by: Bruce Dubbs Owned by: Bruce Dubbs
Priority: normal Milestone: 8.3
Component: BOOK Version: SVN
Severity: normal Keywords:


New minor version.

Change History (4)

comment:1 by Bruce Dubbs, 6 years ago

Owner: changed from blfs-book to Bruce Dubbs
Status: newassigned

comment:2 by Bruce Dubbs, 6 years ago

News about PCRE releases

Release 8.42 20-March-2018

comment:3 by Bruce Dubbs, 6 years ago

Version 8.42 20-March-2018

  1. Fixed a MIPS issue in the JIT compiler reported by Joshua Kinard.
  1. Fixed outdated real_pcre definitions in (patch by Evgeny Kotkov).
  1. pcregrep was truncating components of file names to 128 characters when

processing files with the -r option, and also (some very odd code) truncating path names to 512 characters. There is now a check on the absolute length of full path file names, which may be up to 2047 characters long.

  1. Using pcre_dfa_exec(), in UTF mode when UCP support was not defined, there

was the possibility of a false positive match when caselessly matching a "not this character" item such as [\x{1234}] (with a code point greater than 127) because the "other case" variable was not being initialized.

  1. Although pcre_jit_exec checks whether the pattern is compiled

in a given mode, it was also expected that at least one mode is available. This is fixed and pcre_jit_exec returns with PCRE_ERROR_JIT_BADOPTION when the pattern is not optimized by JIT at all.

  1. The line number and related variables such as match counts in pcregrep

were all int variables, causing overflow when files with more than 2147483647 lines were processed (assuming 32-bit ints). They have all been changed to unsigned long ints.

  1. If a backreference with a minimum repeat count of zero was first in a

pattern, apart from assertions, an incorrect first matching character could be recorded. For example, for the pattern /(?=(a))\1?b/, "b" was incorrectly set as the first character of a match.

  1. Fix out-of-bounds read for partial matching of /./ against an empty string

when the newline type is CRLF.

  1. When matching using the the REG_STARTEND feature of the POSIX API with a

non-zero starting offset, unset capturing groups with lower numbers than a group that did capture something were not being correctly returned as "unset" (that is, with offset values of -1).

  1. Matching the pattern /(*UTF)\C[\v]+\x80/ against an 8-bit string

containing multi-code-unit characters caused bad behaviour and possibly a crash. This issue was fixed for other kinds of repeat in release 8.37 by change 38, but repeating character classes were overlooked.

  1. A small fix to pcregrep to avoid compiler warnings for -Wformat-overflow=2.
  1. Added --enable-jit=auto support to
  1. Fix misleading error message in

comment:4 by Bruce Dubbs, 6 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 20002.

Note: See TracTickets for help on using tickets.