| mpyne |
I'm a bit unconvinced, wihtout it we get a warning if we enable -Wzero-as-null-pointer-constant
but using Z_NULL seems to be more "what the library wants"
If we don't want this, this would be a reason against enabling -Wzero-as-null-pointer-constant
for all the frameworks as i've suggested in the other review
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Actually -Wzero-as-null-pointer-constant is probably a good idea, and this is a correct fix. A decade ago when everything was going from 32 to 64-bits, we ran into a JuK crash bug because we used GST_NULL (or similar) as the null constant for a gstreamer variadic C function, which in C++ mode was 0. Well, C++ didn't know that the 0 was supposed to be a pointer instead of an int, so the function in question crashed because C++ put a 32-bit int on the stack instead of a 64-bit null pointer.
Using nullptr consistently solves this issue, even though it wouldn't be a problem here since C++ can see that the 0 is supposed to convert to a pointer.
The real fix should probably go in zlib, but I wouldn't hold my breath due to the compatibility requirements that I would imagine they maintain.