Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89157
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sevenpercent.solutions designates 46.101.25.58 as permitted sender)
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
References: <CANUQDCh5R3dir=fzb3uGgKUrbk266BR6xWLn4Gt0-OWCOfZtAQ@mail.gmail.com> <563B6ED1.1030601@gmail.com> <CAPwsocG6yU0sKYLaT4DM-KA1HTf6rLr=kn7G88GeduqK7pASGg@mail.gmail.com> <CANUQDChkBEwvHq+8d1UU0d7pKy0MgTcfY38dsCQ898CF86_B6Q@mail.gmail.com> <op.x7uajofhtwp9n2@charlie> <CAPwsocEpk2Ygz48-0Gn5KeChfCj+kacJodU9PKRmxFjmdNQcYg@mail.gmail.com>
Date: Wed, 11 Nov 2015 00:04:12 +0200
To: "PHP Internals" <internals@lists.php.net>
Cc: Leigh <leight@gmail.com>, "Derick Rethans" <derick@php.net>, "Niklas
 Keller" <me@kelunik.com>, "Rowan Collins" <rowan.collins@gmail.com>, "Joe
 Watkins" <krakjoe@php.net>, "Dmitry Stogov" <dmitry@zend.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: SevenPercent Solutions Ltd.
Message-ID: <op.x7wnlatwtwp9n2@charlie>
In-Reply-To: <CAPwsocEpk2Ygz48-0Gn5KeChfCj+kacJodU9PKRmxFjmdNQcYg@mail.gmail.com>
User-Agent: Opera Mail/1.0 (MacIntel)
Subject: Re: [PHP-DEV] Null bytes in anonymous class names
From: steven.hilder@sevenpercent.solutions ("Steven Hilder")

On Mon, 09 Nov 2015 16:48:57, Leigh <leight@gmail.com> wrote:
> On 9 November 2015 at 15:27, Steven Hilder
> Can you share your patch?

See  
https://github.com/php/php-src/compare/master...stevenhilder:hide-anon-class-suffix

Feedback very welcome :)

> It should be possible to return the sanitised name without removing it
> internally.(would have to cover the get_parent_class and getParentClass
> versions too, and have a quick audit of other places class names can be
> spat out.)

Yes, that's what I had in mind. The class names are sanitised only for
display in userland; I haven't changed the way that the names are generated
or stored internally.

I've applied the change to `get_parent_class()` and `get_called_class()`.
Nothing needed to be done for `ReflectionClass::getParentClass()` because  
it
returns another `ReflectionClass` object, not the parent's name.

The `__CLASS__` magic constant and `::class` syntax also needed changes.  
The
patch includes a test which shows all of the scenarios that I've accounted
for. Please do let me know if you can think of any others.

I've also implemented the change to `class_alias()` as I described in my
previous email.

> Can we at least get the memory address hidden (non-debug builds only
> perhaps? - var_dump appends a #n why not just use this number.)

It isn't possible to use the number that `var_dump()` shows, because the
names for anonymous classes are generated during compile-time, so the  
handle
isn't available yet.

On Mon, 09 Nov 2015 21:46:24, Derick Rethans <derick@php.net> wrote:
> On Thu, 5 Nov 2015, Niklas Keller wrote:
>> How about removing that null byte?
>
> I would suggest replacing it with something else. As I am making this  
> work
> for Xdebug, I really need to ship the full name to the IDE so that they
> can later do look-ups on anonymous class properties, and with the \0 the
> IDEs seem to fuck this up. I suggest using another @ instead of the \0.

Derick - forgive me, I'm not at all familiar with how Xdebug+IDE  
integration
works, but can you please elaborate a little on the following...?

* Since Xdebug is an extension, why does the display of class names in
   userland bear any impact?

* If IDEs had access to the filename portion of the class name, how would
   that help them to lookup that specific class (since there could be many
   anonymous classes defined in that one file)?

* Even if IDEs had access to the full anonymous class name - including the
   (unpredictable) memory address of the lexer position at compile-time, how
   would an IDE have any better ability to lookup the correct class?

Kind regards,
Steve