Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <563B6ED1.1030601@gmail.com>
References: <CANUQDCh5R3dir=fzb3uGgKUrbk266BR6xWLn4Gt0-OWCOfZtAQ@mail.gmail.com>
	<563B6ED1.1030601@gmail.com>
Date: Thu, 5 Nov 2015 15:14:47 +0000
Message-ID: <CAPwsocG6yU0sKYLaT4DM-KA1HTf6rLr=kn7G88GeduqK7pASGg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a1145b94a671a920523cc96ac
Subject: Re: [PHP-DEV] Null bytes in anonymous class names
From: leight@gmail.com (Leigh)

--001a1145b94a671a920523cc96ac
Content-Type: text/plain; charset=UTF-8

On 5 November 2015 at 14:59, Rowan Collins <rowan.collins@gmail.com> wrote:

>
> PHP uses null bytes quite a lot to produce deliberately illegal
> identifiers. For instance the old eval-like create_function() [e.g.
> https://3v4l.org/hqHjh] and the serialization of private members [e.g.
> https://3v4l.org/R6Y6k]
>
> In this case, I guess the "@" in "class@anonymous" makes the name illegal
> anyway, but I'm not sold on the null byte being more unacceptable here than
> anywhere else.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> That doesn't mean it's a good approach (*cough* namespaces *cough*), and
these bits of "magic" are supposed to be hidden away from users. I'm
guessing in this particular instance, the point of the null is to make
string operations cut off after "anonymous", however string operations that
respect the zval string length aren't going to do this.

e.g. var_dump() the class name is put through sprintf and it cuts off at
the null, but get_class or ReflectionClass::getName() just returns the
original string, and exposes the implementation details.

--001a1145b94a671a920523cc96ac--