Stefan Roehrich wrote:

> On 2003-08-25 14:54:48, Ard Biesheuvel wrote:
>> Casting to void* instead of void** cures the problem. As the cast
> 
> Yes, but why?

Because a pointer to a pointer isn't untyped (because you know where it 
points to: to an untyped pointer)

> I don't know if with some optimizations void* or zval pointers need
> special alignment.

It's not about alignment (all pointers are always the same size, regardless 
of where they point to) It's about the strict-aliasing code being able to
rely on the fact that your void** pointer doesn't contain the same address
as a zval** or any other pointer (which is unlikely in the case where the
cast value is an actual function argument, like the case we're discussing)

> Yes, or we would be on the safe side if we compile with
> -fno-strict-aliasing, then gcc doesn't do such expression based

... and doesn't whine about it.

> optimizations. Or (as I have seen on some patches for other projects
> after a search for the gcc warning message) we could change the zval**
> data to something like this:
> 
> union {
>   zval **zval;
>   void *ptr;
> } data;

The problem here is that zend_hash_find() is meant to be generic. If you 
look through the code, you will see that it's not only being used for zval
but for other (extension-specific) types as well. Maintaining a union with
all these types would be ludicrous.

> call zend_hash_find(..., &data.ptr) and after this use
> data.zval. Access via unions is allowed because then the data must be
> correctly aligned for both types.

Alignment isn't the problem with pointers. The reason for a union is that 
the compiler can tell for sure that the pointers are aliased. In our case, 
the pointers are _not_ aliased, which could leave room for optimization by 
-fstrict-aliasing.

> The gcc generated code for this variant only uses some other
> registers, otherwise it seems similar.

I expect it to be identical to code generated for different variables that 
are known to contain the same address.

Ard

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to