> account that every pointer in scope might be an alias of the resulting
> value. __attribute_malloc__ fixes that. (Disabled for non-GCC compilers)
What about erealloc? It can return the same pointer as
passed to it.
> 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].
Segfaulting early is a good thing. Whenever a crash occurs a
defect has been found and needs to be fixed. If the NULL would
just be silently ignored, the real bug (where NULL is
erroneously inserted) could slip by and make it into a
release.
> 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.
Then you would also need a _set function which rejects NULL
values. Considering that the existing APIs have worked quite
well in the past, I don't see a need for adding such a class
of APIs.
> 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 think we should address them. Many warnings provide
information about potential defects, but the flood of aliasing
warnings deters developers from considering the relevant
ones.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
