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
