Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92431
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.215.66 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAESVnVpP2xnidOevwcmDHmO4-6LiES1ThegTedOhOqou_Hf3Tw@mail.gmail.com>
References: <CAESVnVpP2xnidOevwcmDHmO4-6LiES1ThegTedOhOqou_Hf3Tw@mail.gmail.com>
Date: Mon, 18 Apr 2016 16:24:09 -0700
Message-ID: <CAESVnVrvmCPrtP6NXtb7LHeTh+MWOxqowGoBaC9bYnrk_JShLg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC] [Discussion] Octal overflow detection
From: pollita@php.net (Sara Golemon)

On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon <pollita@php.net> wrote:
> https://wiki.php.net/rfc/octal.overload-checking
> Because having this expression evaluate to true makes me sad: ("\000"
> === "\400")
>
I haven't heard any responses on this and wanted to bump it back to
the top of your newsreaders.

For the record, my inclination is to raise a warning on octal
overflow, but not change behavior (at least, not for 7.1, perhaps
later).

Note that this warning would bubble up during the lexing phase, so an
opcache would prevent it from raising on every page load.  That's
probably fine, the alternative is to signal the parser to bake it into
the ast output and that's way over-engineered.

-Sara