[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190412114845.GZ23599@brightrain.aerifal.cx>
Date: Fri, 12 Apr 2019 07:48:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: use of varargs in open and various functions
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
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.
