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