https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91187

Alejandro Colomar <alx at kernel dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alx at kernel dot org

--- Comment #10 from Alejandro Colomar <alx at kernel dot org> ---
(In reply to Harald van Dijk from comment #9)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Albert Astals Cid from comment #0)
> > > #define Z_NULL 0
> > 
> > N.B. this is actually a bug. Using Z_NULL where a null pointer is expected
> > might cause bugs e.g. execl("foo", "foo", Z_NULL) can pass a 32-bit int
> > where a 64-bit pointer is expected, leading to undefined behaviour.
> 
> Whether this is a bug in the definition of Z_NULL depends on how Z_NULL is
> meant to be used. If it is not supported as a variadic function argument,
> the fact that it does not work as a variadic function argument is not a bug.
> 
> zlib.h's definition contains a comment:
> 
>   #define Z_NULL  0  /* for initializing zalloc, zfree, opaque */
> 
> This does not include calling variadic functions.
> 
> > So maybe the warning should be taken as an opportunity to fix the code (or
> > report a bug to the library) to use something safer:
> > 
> > #if __cplusplus
> > #define Z_NULL nullptr
> > #else
> > #define Z_NULL 0L
> > #endif
> 
> If Z_NULL is meant to be usable as a variadic function argument, this is
> wrong too. There is no guarantee that 0L is the same size as a pointer
> (think W64). There is not even a guarantee that NULL is the same size as a
> pointer.

Maybe not a bug if you're sure it will never be used for variadic functions,
but that is still a bad definition of Z_NULL.  Why not this?

#ifdef __cplusplus
#define Z_NULL nullptr
#else
#define Z_NULL NULL
#endif

Reply via email to