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

2013-09-28 Thread Tim Shen
On Fri, Sep 27, 2013 at 4:30 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
 Nah, only double check that the testcase you are un-xfail-ing uses 
 -std=gnu++11, otherwise will not pass ;)

Committed :)

Thanks!


-- 
Tim Shen


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

2013-09-27 Thread Jonathan Wakely
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.


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

2013-09-27 Thread Paolo Carlini

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.


Paolo.


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

2013-09-27 Thread Jonathan Wakely
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
  }


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

2013-09-27 Thread Tim Shen
On Fri, Sep 27, 2013 at 9:37 AM, Jonathan Wakely jwakely@gmail.com wrote:
 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
   }

Sorry for late .

Do I need to bootstrap again?


-- 
Tim Shen


a.patch
Description: Binary data


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

2013-09-27 Thread Paolo Carlini


Hi

Tim Shen timshe...@gmail.com ha scritto:
Do I need to bootstrap again?

Nah, only double check that the testcase you are un-xfail-ing uses 
-std=gnu++11, otherwise will not pass ;)

Paolo



[Patch] Let ordinary escaping in POSIX regex be valid

2013-09-26 Thread Tim Shen
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

Thanks!


-- 
Tim Shen


a.patch
Description: Binary data