[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Aug 2014 10:52:54 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: variadic args (was: compiling musl on x86_64 linux with pcc)
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
