On Tue, Jan 15, 2019 at 1:42 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Jan 15, 2019 at 1:09 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> About using "int" as return type for getId(): >> >> > * Can the `getId()` return type be restricted to either `int` or >>> > `string`? Why is it a union type right now? Technical limitation? >>> >>> To allow changes in the future. The real return value here is an int, but >>> the size increase due to hashing makes it a string. If we find a way to >>> avoid that (or decided that we don't care about leaking addresses), we >>> could change this to a (faster) int-based API. >>> >> >> spl_object_hash() uses a XOR to hide internal addresses - so they're >> already "leaking". >> we also added spl_object_id() which proved much better in term of memory >> usage - not only CPU. >> >> Mixing both arguments/approaches, what about returning a XORed int? Are >> we OK with that? It'd be a welcome storage/CPU optimization from my pov. >> > > A XORed int is not much better than returning the address directly -- it > will scramble the base address, but for example not the offsets between the > references (if the XOR key is the same). > > If people think that this is good enough for us, then of course it's > better to go with the int for performance reasons. I've picked the sha1 > here to be conservative. How performance critical is this API? > > Nikita > I'd like to move forward with the RFC as is -- I'm uncomfortable with switching this to a simple XOR for security reasons. I think we should start off with the current implementation, with the option of switching to an integer return value at a later time. Nikita
