From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14073 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: use of varargs in open and various functions Date: Fri, 12 Apr 2019 07:48:45 -0400 Message-ID: <20190412114845.GZ23599@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="168514"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14089-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 12 13:49:00 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hEug0-000hlZ-Lh for gllmg-musl@m.gmane.org; Fri, 12 Apr 2019 13:49:00 +0200 Original-Received: (qmail 17840 invoked by uid 550); 12 Apr 2019 11:48:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17815 invoked from network); 12 Apr 2019 11:48:57 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14073 Archived-At: On Thu, Apr 11, 2019 at 06:36:31PM +0200, Norbert Lange wrote: > > On Thu, Apr 11, 2019 at 04:25:50PM +0200, Norbert Lange wrote: > > > Hello, > > > > > > I had some dealings with software that forwards arguments from vararg functions, > > > the kind with optional but known fixed type. > > > open, fcntl, ioctl are some examples. > > > > > > What happens in musl is that the optional argument is optionally or > > > always retrieved (fcntl). > > > I think this is pretty much pointless, > > Tough. The interfaces are just defined this way. In case of fcntl, it > > is merely a convenience of circumstance that allows musl to do what it > > does. fcntl()'s third argument can be a pointer to various structures, > > or an unsigned long. Linux requires a C implementation where pointers > > can be losslessly converted to long and back, but that is the only > > reason this call to va_arg() works. > > Those are C interfaces, they can be implemented in any language you > you see fit. > if you write asm, you can just pick the registers or pull the values from > the stack. > declaration can and should stay the same, no point stressing this further. I think what you're not understanding is that the goal of musl is not to provide C that translates into asm/machine code that matches a particular ABI. It's to provide C that's valid as C, which makes it useful and interesting in a much larger context and relevant to the future, where C very well may be consumed mainly in some kind of memory-safe abstract machine that has little to do with our current conceptions of machine ABIs, rather than just the present. Naturally, the C library can't be implemented entirely in C, so this goal is always incomplete. The adapted version of this goal then becomes minimizing the amount of code that's not portable C (i.e. asm source files, inline asm, C extensions, code that's C but that assumes particular addressing/stack/etc. models, ...) to what's strictly necessary. Rich