Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAEYWF=5EdSQm+esdbCJE+D-kb50h_QhpOQ27B-JCxqXma-Yibw@mail.gmail.com>
References: <CAPg3XxJSctvZL_DTdZtge+xoAbgeQjoMhYjndc107Jjk_KFO9g@mail.gmail.com>
	<CAEYWF=5EdSQm+esdbCJE+D-kb50h_QhpOQ27B-JCxqXma-Yibw@mail.gmail.com>
Date: Fri, 2 Oct 2015 10:04:58 -0700
Message-ID: <CAESVnVo1LXG=01FhR2h=zhKW1YCUusi5pRiFzzZzEaf+ivyBfw@mail.gmail.com>
To: Bishop Bettini <bishop@php.net>
Cc: Peter Cowburn <petercowburn@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Strings, invalid escape sequences and parse errors
From: pollita@php.net (Sara Golemon)

On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini <bishop@php.net> wrote:
> On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn <petercowburn@gmail.com>
> 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 instead keeping the literal characters
>>
>> or c) tell me to keep quiet and accept the oddball behaviour, having quirks
>> is The PHP Way after all.
>>
>
> Well, I think option (a) would break parsed strings containing regex:
>
Oh holy hell.  I was about to point towards A because I agree with
Andrea that our invalid escape handling makes no sense, then you throw
this wrench in the gears.

While I still think that ignoring invalid sequences is bad and a
recipe for disaster (for example, in a given regex string, you have
some "escapes" passed to the engine as-is, while others like
\t\v\f\r\n do get interpolated, which is so inconsistent and entirely
php it's practically its own meme), I have to be practical about the
fact that there is a TON of existing regex out there (and no small
amount of "\u1234" sequences in JSON blobs).  A ton of that existing
regex is also needlessly using double-quotes strings where
single-quotes would have worked, meaning we can't just bifurcate on
that (even though allowing invalid sequences through on single-quotes
makes some sense).

Ugh...   No, that's too big of a change to existing scripts.  Can't do
option A, much as I'd like.

> 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 confidence that something is wrong.  Again, I
believe in it, but the arguments against option A illustrate why it
might not be practical.  I hate to say this, but in the interest of
consistency (were 7.0 not in its final stage) I'd vote for B.

> which if so leaves (c.ii): accepting the odd-ball behavior....
>
Given that 7.0 is in its final stage, and changing this behaviour is
probably a non-starter at this point.  C seems the most sane^W
pragmatic.  It's not the first inconsistency PHP's picked up, it won't
be the last.

-Sara