Re: Null bytes in anonymous class names

From: Date: Tue, 10 Nov 2015 22:04:12 +0000
Subject: Re: Null bytes in anonymous class names
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-89157@lists.php.net to get a copy of this message
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

« previous php.internals (#89157) next »