Date: Wed, 29 Jul 2020 23:22:51 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 229925] [EXP-RUN] Disallow escaping ordinary characters in regex(3) Message-ID: <bug-229925-7788-3QeAn9k8yn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-229925-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-229925-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229925 --- Comment #37 from commit-hook@FreeBSD.org --- A commit references this bug: Author: kevans Date: Wed Jul 29 23:21:57 UTC 2020 New revision: 363679 URL: https://svnweb.freebsd.org/changeset/base/363679 Log: regex(3): Interpret many escaped ordinary characters as EESCAPE In IEEE 1003.1-2008 [1] and earlier revisions, BRE/ERE grammar allows for any character to be escaped, but "ORD_CHAR preceded by an unescaped <backslash> character [gives undefined results]". Historically, we've interpreted an escaped ordinary character as the ordinary character itself. This becomes problematic when some extensions give special meanings to an otherwise ordinary character (e.g. GNU's \b, \s, \w), meaning we may have two different valid interpretations of the same sequence. To make this easier to deal with and given that the standard calls this undefined, we should throw an error (EESCAPE) if we run into this scenario to ease transition into a state where some escaped ordinaries are blessed with a special meaning -- it will either error out or have extended behavior, rather than have two entirely different versions of undefined behavior that leave the consumer of regex(3) guessing as to what behavior will be used or leaving them with false impressions. This change bumps the symbol version of regcomp to FBSD_1.6 and provides = the old escape semantics for legacy applications, just in case one has an old= er application that would immediately turn into a pumpkin because of an extraneous escape that's embedded or otherwise critical to its operation. This is the final piece needed before enhancing libregex with GNU extensi= ons and flipping the switch on bsdgrep. [1] http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/ PR: 229925 (exp-run, courtesy of antoine) Differential Revision: https://reviews.freebsd.org/D10510 Changes: head/contrib/netbsd-tests/lib/libc/regex/data/meta.in head/contrib/netbsd-tests/lib/libc/regex/data/subexp.in head/lib/libc/regex/Symbol.map head/lib/libc/regex/regcomp.c --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-229925-7788-3QeAn9k8yn>