From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5922 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: variadic args (was: [musl] compiling musl on x86_64 linux with pcc) Date: Wed, 27 Aug 2014 10:52:54 +0200 Message-ID: <20140827085254.GJ12376@example.net> References: <20140813123832.GK12888@brightrain.aerifal.cx> <20140813125607.GK5170@example.net> <20140813142332.GN12888@brightrain.aerifal.cx> <20140825082807.GB12376@example.net> <20140825083457.GC12376@example.net> <20140825154617.GV12888@brightrain.aerifal.cx> <20140826193439.GH12376@example.net> <20140826195407.GG12888@brightrain.aerifal.cx> <20140827074036.GI12376@example.net> <20140827075407.GL12888@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409129606 25658 80.91.229.3 (27 Aug 2014 08:53:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 08:53:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5929-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 27 10:53:19 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XMYyk-0005kU-7h for gllmg-musl@plane.gmane.org; Wed, 27 Aug 2014 10:53:18 +0200 Original-Received: (qmail 22040 invoked by uid 550); 27 Aug 2014 08:53:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22032 invoked from network); 27 Aug 2014 08:53:15 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe06.swip.net; client-ip=62.210.74.137; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140827075407.GL12888@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5922 Archived-At: 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: ... otherwise expecting the compiler to implement the following builtins: 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