On Tue, Apr 30 2019, Nam Nguyen <n...@berkeley.edu> wrote: > This is an update for devel/pcre2 10.33, released April 16, 2019. I > tested it with wget.
Also tested with devel/vte3 and shells/fish but the update looked safe anyway. > Changelog: https://www.pcre.org/changelog.txt > > Here is some commentary on relevant parts of the changelog. > > --8<---------------cut here---------------start------------->8--- > 3. Added support for callouts from pcre2_substitute(). After 10.33-RC1, but > prior to release, fixed a bug that caused a crash if pcre2_substitute() was > called with a NULL match context. > > comment: minor bump pcre2-{8, 16, 32} because added new function > > +T pcre2_set_substitute_callout_8 yep > 4. The POSIX functions are now all called pcre2_regcomp() etc., with wrapper > functions that use the standard POSIX names. However, in pcre2posix.h the > POSIX > names are defined as macros. This should help avoid linking with the wrong > library in some environments while still exporting the POSIX names for > pre-existing programs that use them. (The Debian alternative names are also > defined as macros, but not documented.) > > comment: minor bump pcre2-posix. Added new functions, while redefining > old symbols, like regcomp --> pcre2_regcomp. > > +T pcre2_regcomp > +T pcre2_regerror > +T pcre2_regexec > +T pcre2_regfree > > -PCRE2POSIX_EXP_DECL int regcomp(regex_t *, const char *, int); > -PCRE2POSIX_EXP_DECL int regexec(const regex_t *, const char *, size_t, > +PCRE2POSIX_EXP_DECL int pcre2_regcomp(regex_t *, const char *, int); > +PCRE2POSIX_EXP_DECL int pcre2_regexec(const regex_t *, const char *, size_t, > regmatch_t *, int); > -PCRE2POSIX_EXP_DECL size_t regerror(int, const regex_t *, char *, size_t); > -PCRE2POSIX_EXP_DECL void regfree(regex_t *); > +PCRE2POSIX_EXP_DECL size_t pcre2_regerror(int, const regex_t *, char *, > size_t); > +PCRE2POSIX_EXP_DECL void pcre2_regfree(regex_t *); > + > +#define regcomp pcre2_regcomp > +#define regexec pcre2_regexec > +#define regerror pcre2_regerror > +#define regfree pcre2_regfree yep > 6. Implement PCRE2_EXTRA_ESCAPED_CR_IS_LF (see Bugzilla 2315). > > comment: minor bump because new symbol in pcre2.h > > +#define PCRE2_EXTRA_ESCAPED_CR_IS_LF 0x00000010u /* C */ > > 10. Implement PCRE2_COPY_MATCHED_SUBJECT for pcre2_match() (including JIT via > pcre2_match()) and pcre2_dfa_match(), but *not* the pcre2_jit_match() fast > path. Also, when a match fails, set the subject field in the match data to > NULL > for tidiness - none of the substring extractors should reference this after > match failure. > > comment: minor bump because new symbol in pcre2.h > > +#define PCRE2_COPY_MATCHED_SUBJECT 0x00004000u > 26. With PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL set, escape sequences such as \s > which are valid in character classes, but not as the end of ranges, were being > treated as literals. An example is [_-\s] (but not [\s-_] because that gave an > error at the *start* of a range). Now an "invalid range" error is given > independently of PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL. > > comment: minor bump because new error code in pcre2_error.c "invalid > range in character class\0" > 31. Implemented PCRE2_EXTRA_ALT_BSUX to support ECMAScript 6's \u{hhh} > construct. > > comment: minor bump because new symbol in pcre2.h > +#define PCRE2_EXTRA_ALT_BSUX 0x00000020u /* C */ Technically not symbol additions, but fine, they might warrant a minor bump anyway. > 23. The RunGrepTest script used to cut out the test of NUL characters for > Solaris and MacOS as printf and sed can't handle them. It seems that the *BSD > systems can't either. I've inverted the test so that only those OS that are > known to work (currently only Linux) try to run this test. > > comment: Now that the test checks for Linux, I am proposing to > s/Linux/OpenBSD/ in the patch that jca@ added. This seems to be the > easiest way to run this test now. > > previous version: > uname=`uname` > if [ "$uname" != "SunOS" -a "$uname" != "Darwin" ] ; then > ... > > newest version: > uname=`uname` > case $uname in > Linux) > ... This is just badly implemented, portability-wise. sed can't portably handle NUL characters, so sed shouldn't be used here. Your change looks fine as a workaround for our ports tree, though. Diff committed, thanks! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
