removing SET_NON_ZERO_NULL
Chip Salzenberg
are not represented as all zeroes, the null pointer value is still
*spelled* "0" in source code. C<FOO *p = 0> always works, for all
values of FOO and all architectures.
If I'm missing something, please speak up.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
Open Source is not an excuse to write fun code
then leave the actual work to others.
Nicholas Clark
> The SET_NON_ZERO_NULL macro is silly. On any arch where null pointers
> are not represented as all zeroes, the null pointer value is still
> *spelled* "0" in source code. C<FOO *p = 0> always works, for all
> values of FOO and all architectures.
>
> If I'm missing something, please speak up.
You might be, although it's taken me a few hours to remember this one.
Is it being used as part of an optimisation? Is it so that memory for
structures can be allocated with calloc() (or later reset to all bits zero)
and then in the source to reset that structure a macro used to write
0 to all the pointers? On a platform where a NULL pointer is all bits zero,
that macro can be a no-op, so the code is (or should) be faster.
I think that Leo put some effort in trying make the code to use calloc()
or similar functions where possible to speed up initialisation.
If we're doing this, should we have one for floats, doubles and long doubles
having some representation for 0.0 other than all bits zero? :-)
(Or is this where someone with better knowledge of the C standard that me
tells me that ANSI mandates that all bits zero must be an in-memory
representation of 0.0 for floating point types?)
Nicholas Clark
Chip Salzenberg
> Is it being used as part of an optimisation? Is it so that memory for
> structures can be allocated with calloc() (or later reset to all bits zero)
> and then in the source to reset that structure a macro used to write
> 0 to all the pointers? On a platform where a NULL pointer is all bits zero,
> that macro can be a no-op, so the code is (or should) be faster.
That's it. Thanks for saving me a commit-and-revert cycle.
> If we're doing this, should we have one for floats, doubles and long
> doubles having some representation for 0.0 other than all bits zero? :-)
I think so. While POSIX may specify IEEE floating point, I doubt that
ANSI does. :-,