This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Let ordinary escaping in POSIX regex be valid
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Tim Shen <timshen91 at gmail dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 27 Sep 2013 14:37:10 +0100
- Subject: Re: [Patch] Let ordinary escaping in POSIX regex be valid
- Authentication-results: sourceware.org; auth=none
- References: <CAPrifD=NxYmDzZL1H7qm7Oysc-bC_A+TEEGNiYwwcuq-UfK=Zg at mail dot gmail dot com> <CAH6eHdTfv5vLh+d8hCc0o3AF9FtHRcYrxnvmWA7X6OsQn4bKDg at mail dot gmail dot com> <52457AFB dot 7030800 at oracle dot com>
On 27 September 2013 13:32, Paolo Carlini wrote:
> On 9/27/13 4:34 AM, Jonathan Wakely wrote:
>> On 27 September 2013 03:15, Tim Shen wrote:
>>> POSIX ERE says that escaping an ordinary char, say R"\n" is not
>>> permitted, because 'n' is not a special char. However, they also say
>>> that : "Implementations are permitted to extend the language to allow
>>> these. Conforming applications cannot use such constructs."
>>> So let's support it not to make users surprised.
>>> Booted and tested under -m32 and -m64
>> I'm wondering whether we want to have a stricter mode that doesn't
>> allow them, to help users avoid creating non-portable programs. We
>> could check the value of the preprocessor macro __STRICT_ANSI__, which
>> is set by -std=c++11 but not by -std=gnu++11, although that's not
>> really the right flag. We want something more like the GNU shell
>> utils' POSIXLY_CORRECT.
> Indeed. I think that for now __STRICT_ANSI__ can do, it's important to
> manage to accept those otherwise, as we discovered yesterday, we easily
> reject quite a few rather sensible regex users can write or find in
> examples: this started when Tim, upon my suggestion, tried the examples in
> the new edition of Nicolai Josuttis book and found in one those an escaped
> closed curly bracket (note, closed, open are definitely fine), which
> apparently most of the other implementations do not reject.
Ah I see. I definitely agree it's good to accept that instead of
being unnecessarily strict, but other people will want the option of
strict conformance, so I think we can please everyone with something
_M_token = _S_token_ord_char;