variadic args (was: [musl] compiling musl on x86_64 linux with pcc)

[u-igbb@aetey.se]

On Wed, Aug 27, 2014 at 03:54:07AM -0400, Rich Felker wrote:
> > I am possibly not realizing some crucial bit but I do not see why the
> > implementation of stdarg.h must be the business of the library. If the
> 
> Because other headers need to know how to get va_list defined for use
> in function prototypes, and they can't include stdarg.h because it
> would expose more than they want. glibc handles this by making use of

I guess this is the matter which everything revolves around.
What is it that stdarg.h would expose too much?

> a special inclusion protocol between the glibc headers and the gcc
> headers: it defines a special macro before including stdarg.h telling
> gcc that it just wants the definition of va_list and nothing else.

Wonder whether it would be reasonable to say that musl expects from
every compiler to be used with the library either
a stdarg.h with following properties: ...
 <which ones?>
otherwise expecting the compiler to implement the following builtins:
 <the current contents of musl's stdarg.h>

I do not see how this would hurt in any way.

By the way, this - in any case - *is* an interface against the compiler.

As a matter of fact, the bultins naming differs between compilers.

So the current musl approach is to just boldly assume a *certain*
relatively arbitrary interface, not "the only possible" nor "the only
reasonable one".

> > A compiler used *together* with the library may lack the builtins but it
> > still can be fully compatible even if in some situations less efficient.
> 
> No, it can't. There is simply no way to express, in C, the concept of
> "get the next variadic argument" without __builtin_va_arg or something
> 100% equivalent to it. If you have a compiler than chooses to be

Wait, this is not a library busyness, this is something which happens
_inside_ a function. Passing variadic arguments between internal functions
can also be left to the compiler and this should not have to be reflected
in the library's public headers.

I will when I can make an extra round of reading the musl source to
try to see the implications - for the moment the point is evading me.

> Again, this has nothing to do with ABI between external variadic
> functions. It's a matter of the inability to express to the compiler
> what you want it to do (get the next variadic argument) in plain C.

It is of course only the compiler who knows how to do va_arg, but its
internal knowledge can be expressed *either* by __builtin_va_arg *or*
by an include file defining va_arg in a compiler-specific fashion
*or even* by implementing va_arg as a function like tcc does.

I do not argue that not-builtins are "good" but frankly I do not see
how these non-builtins-ways to express the compiler specific details
are contradicting standards or compatibility.

The difference from a builtin is that a definition in a header is "less
opaque", but the preprocessor macros are a natural abstraction layer in
C and are not supposed to be looked behind.

Rune