[MPlayer-dev-eng] [PATCH] cast null pointers

Christian Weisgerber naddy at mips.inka.de
Thu Aug 12 19:43:00 CEST 2010


Rowan James:

> My understanding was that this was not just a stylistic issue,
> as the constant 0 expression could result in incorrect handling of
> stdarg-style parameter lists; the parsing code may assume that all
> arguments are pointer-sized; which would not be the case if an
> integer zero was expanded when NULL was encountered - the
> 'not-end-of-args' test may pass and try to read another 64-bit chunk
> on 64-bit architectures where only the 32-bit integer existed; since
> the determination of number and type of passed parameters is entirely
> up to the called code.

Correct.

In practice, things conspire to save your ass.  On 32-bit platforms,
ints and pointers are the same size anyway.  On typical 64-bit
platforms (e.g. alpha, amd64, sparc64), the first n parameters are
passed in registers, where (1) n is sufficient to cover most function
calls and (2) putting a 32-bit 0 into a register will clear all 64
bits.

> However, in my experience, it's typical for NULL to expand to not
> '0', but '(void*)0', which would effectively implement this change
> anyway.

Or __null for GCC, or 0L, or 0.  OpenBSD uses 0L, which will also
be pointer-sized, since there is so much broken code out there.

That you need to explicitly cast NULL to a pointer when passed as
an argument to a variadic function is a basic fact of the C language.
For functions instrumented with __attribute__((sentinel)), gcc will
happily warn you if you don't.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de


More information about the MPlayer-dev-eng mailing list