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 *).
This is not about size, but about aliasing.
When compiling zend_hash.c, the compiler didn't expect void **pData to really be a zval**, so any zval**s inside zend_hash_find() are assumed not to alias with pData. If you cast a typed pointer function argument to a different-typed pointer, GCC just warns you that strict-aliasing rules are violated.
I've fixed it in interbase.c by casting to void* instead of void**. This fix is good enough for me. It would be nice, though, to have as few meaningless warnings as possible, so the real issues stand out.
The other issue I was pointing out is that some pieces of code blindly dereference pointers returned by zend_hash_find(), while the comment states that a result of SUCCESS doesn't imply that the pointer is non-null. Instead of checking for SUCCESS, the code should really check the validity of the pointer. I was merely suggesting a function that returns the pointer and forgets about the result. Not that important though.
Not sure about __attribute_malloc__ - it sounds reasonable but I have no experience with it. Were you able to measure any performance difference?
I'll have to come up with a good malloc()-heavy test case.
Maybe you have a suggestion ?
I expect the effect to be significant, though, because (as I pointed out) the void* return-type of [e]malloc() causes it to alias with every pointer variable in scope, which severely limits the applicability of certain GCC optimizations.
Ard