Re: [Patch] Let ordinary escaping in POSIX regex be valid

[Jonathan Wakely <jwakely dot gcc at gmail 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
like:

else
  {
#ifdef __STRICT_ANSI__
    __throw_regex_error(regex_constants::error_escape);
#else
   _M_token = _S_token_ord_char;
   _M_value.assign(1, __c);
#endif
  }