Re: Null bytes in anonymous class names

On Tue, Nov 10, 2015 at 11:04 PM, Steven Hilder < steven.hilder@sevenpercent.solutions> wrote: 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. > I'd like to clarify some things here from the perspective of the people who implemented this naming scheme. The naming was chosen to be this way intentionally, to combine two behaviors we would like to have: a) Things like get_class() MUST return a class name that uniquely identifies the anonymous class. You should be able to instantiate a new instance of the same class based on it, etc. Having these return truncated names is an absolute no-go, because it would require people to explicitly handle anonymous classes in many context that currently "just work". b) We do not want to display the fully mangled name of an anonymous class in error messages or debug dumps. While the information contained there can be useful, it also significantly bloats outputs. Furthermore we will likely change the exact naming structure in the future, in which case the anonymous class name will no longer contain any directly useful information (maybe some hash). Using a NUL byte conveniently achieves both of these goals. We did not however take into account that this would cause issues with 3rd party tooling that does not support binary data. As such, we may have to change the naming. However we must retain goal a) and would like to retain b). To do this we could use names along the lines of class@anonymous$1, where the uniquely-identifying information is short enough to be no bother when displayed. Generating these kinds of names is non-trivial if you consider caching and may require some changes to the way we perform class bindings. (As a side bonus, depending on how this is done, we might fix https://bugs.php.net/bug.php?id=64291 as well.) Not sure if this is still in scope for PHP 7.0. Nikita