Re: zend_hash_add_or_update flaw

By the way, I just checked the glibc assembly routine and it seems to be quite a bit slower. The i686 version is like 20 assembly commands and it looks as if it's implemented as a function (unless gcc takes care of it earlier). Anyway, I don't think there's a nice way around it but it's a bit annoying that we need to convert to memcpy(). Maybe if the third parameter of memcpy() is a constant some compilers will detect and optimize it? I do remember on some systems memcpy() being a compiler internal function and according to its nature the compiler either calls a C function or create the assembly itself. So we would keep it as memcpy(dst, src, sizeof(void *)); I don't really care about not using pDataPtr for smaller than void * data. The second we put nDataSize as the third parameter we can say bye bye to any compiler optimization. This is of course, if we actually know (and I don't) if some compilers would optimize this. Andi At 09:50 PM 12/6/00 +0100, Sascha Schumann wrote:

Right. It doesn't work with unaligned data but did you actually bump into such a case in PHP? I prefer not moving to memcpy() unless this is actually the case.

    Yes (please refer to my first message). We are basically
    strtok'ing through a string and adding parts of that string
    to the hash.

    memcpy is often implemented as an inline function or even
    assembler by the C library, so the speed impact should be
    negligible.

    - Sascha

--- Andi Gutmans <andi@zend.com> http://www.zend.com/