The other thing is, that a lot of warnings are being triggered by invocations of zend_hash_find(). This function stores its result in the location pointed to by a void** argument, and returns an int specifying whether the key was found or not. As the comment in the source states, this was a conscious decision, because hashes can also be used to store null pointers.
After looking through some of the code, I found out that in a lot of cases, the pointers are expected not to be zero, and are being dereferenced in the code that immediately follows it [without checking for validity first].
Wouldn't it be more straight-forward to introduce an analogue for zend_hash_find() (eg. 'void *zend_hash_get()') which returns the stored pointer [or NULL on failure]. It could be used for applications where null pointers aren't allowed, and fix current code, where the implicit assumption is made the SUCCESS means the the pointers is non-null.
Last of all, I would like to know if we care about the warnings. Personally I don't really mind, as GCC's capabilities of accurately identifying violations of strict-aliasing rules are limited anyway.
I'd just make gcc shut up about it. Using void ** is the generic way to do what we want to do and I see no reason to introduce another way that works only in a subset of the cases, and will require tons of code changes. I have to admit I still haven't been able to figure out what gcc thinks is wrong with casting a zval *** pointer to a void **, considering that any pointer can be cast to a void *, and that pointers always have the same size (i.e., any pointer is castable to void *).
Not sure about __attribute_malloc__ - it sounds reasonable but I have no experience with it. Were you able to measure any performance difference?
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
