Re: musl as a framework to test applications' compatibility with POSIX (was: NULL)

[Rich Felker <dalias@aerifal.cx>]

On Mon, Jan 14, 2013 at 06:30:25PM +0400, Vasily Kulikov wrote:
> On Mon, Jan 14, 2013 at 09:03 -0500, Rich Felker wrote:
> > On Mon, Jan 14, 2013 at 12:45:27PM +0400, Vasily Kulikov wrote:
> > > In musl libc it can be implemented as -DI_WANT_TO_DETECT_GCCISMS.
> > 
> > At the very least, this would have to be a macro in the reserved
> > namespace. However, I'm skeptical of using musl as a tool for checking
> > this, especially since the check only works on 64-bit systems and does
> > not help the compiler produce a warning/error, but only causes random,
> > hard-to-diagnose crashes. It looks like cppcheck is adding (or has
> > already added?) a test for incorrectly passing NULL to variadic
> > functions, which is probably where the check belongs.
> 
> My thought related to this specific bug was a bit more complex:
> 
> 1) on each call of a variadic function save the list of all types
> 2) on each call to va_arg(ap, T) check whether the current argument was
> pushed as T in the saved list
> 
> It would catch not only NULL/(void *)NULL, but also int/long or
> void*/long bugs.
> 
> Now I see that while it is possible to implement (2) in libc redefining
> va_XXX() macros, but it looks like (1) has to be implemented in compiler.

Both require support by the compiler. It's impossible to implement
va_arg without a compiler builtin. Traditionally it was done with
UB-invoking pointer arithmetic on archs where the arguments are passed
on the stack, but even this is invalid and will break under compiler
optimizations such as inlining or reordering local vars for cache
locality purposes.

Also, unfortunately, it's an ABI issue. Making this change would
create a completely separate ABI.

I think static analysis is really the way to go; unfortunately, it
requires some degree of additional markup to specify the argument
types contract.

Rich