Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

Hey Sara, Sara Golemon wrote: On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini wrote: Option (b) sounds reasonable, but there's probably A Solid Reason it was implemented that way AIUI, the "solid reason" was because it's dangerous to fail silently where you have high

Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

Hi, Tom Worster wrote: I agree with Sara all the way except the opinion that it's too late to fix this bug with option B, which I think is the right one. I simply don't know if it is too late or not so I suggest Peter enter a bug report and see what happens. If it's too late for 7.0.0 do it

Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn wrote: > a) change all other "invalid" escape sequences to be a parse error [that > would mean "\m" would raise a parse error!] > > b) change \u{} to behave like any other escape sequence, by not raising a > parse error and

[PHP-DEV] Strings, invalid escape sequences and parse errors

Happy Friday, internals! Prior to PHP 7, any "invalid" escape sequences within strings (as far as I can see) were ignored and the characters treated literally. For example: "\xGG" ("broken" hex sequence) gives "\xGG", "\99" ("broken" octal sequence) gives "\99", "\m" (not a recognised sequence at

Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini wrote: > On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn > wrote: > >> a) change all other "invalid" escape sequences to be a parse error [that >> would mean "\m" would raise a parse error!] >> >> b) change \u{}

Re: [PHP-DEV] Strings, invalid escape sequences and parse errors

On 10/2/15 1:04 PM, Sara Golemon wrote: On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn wrote: a) change all other "invalid" escape sequences to be a parse error [that would mean "\m" would raise a parse error!] b) change \u{} to behave like any other escape sequence,