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.