[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150305210218.GA22539@wilbur.25thandClement.com>
Date: Thu, 5 Mar 2015 13:02:18 -0800
From: William Ahern <william@...handClement.com>
To: musl@...ts.openwall.com
Subject: Re: MUSL Feature Detection
On Thu, Mar 05, 2015 at 10:34:22AM -0500, stephen Turner wrote:
> On Mar 5, 2015 3:58 AM, <u-wsnj@...ey.se> wrote:
> > On Thu, Mar 05, 2015 at 09:33:15AM +0100, u-wsnj@...ey.se wrote:
> > > On Wed, Mar 04, 2015 at 12:54:58PM -0800, William Ahern wrote:
<snip>
> > > > Is there any interest in supporting any kind of feature detection,
> > > > such as an API that communicates implementation choices wrt
> unspecified and
> > > > undefined behavior.
> >
> > I did not mean to comment on this in the previous message.
> >
> > It looks otherwise reasonable but amounts to a standardization effort
> > for a new API with exactly the details intentionally omitted by
> > the existing standards. This might be hard to accomplish.
> >
> > Rune
> >
>
> Ok im going to show my programming ignorance here.
>
> Isnt libc a set of functions built to use I guess they are abi calls? The
> short almost command looking bits like segsrv? So then if someone wanted to
> test libc they would just have to write a macro or something that calls the
> functions individually and uses them in a small reversible if needed test
> case to say " yea we got that feature " ? That would also be good for
> verifying the libc isnt corrupted assuming there isnt already some test
> case like it.
>
> Wouldnt something like that be more helpful than a libc version and a
> assumption its standard full featured and unmodified?
I understand and basically agree with the arguments against defining a
version macro or symbol. I don't think anybody disagrees with the argument
that feature detection is the preferable route. It's just not sufficient.
The kind of feature detection I had in mind isn't simply whether or not a
specific API is provided. That can be accomplished pretty easily with
autoconf. I probably wasn't sufficiently clear on that in the beginning.
But some implementation-defined behaviors are impractical or impossible to
programmatically determine. Most obvious in this case is thread-safety.
Theoretically you could implement a test to determine whether shared buffers
are used, but knowing that doesn't 100% resolve the question, because there
could be other thread-safety issues. Or maybe the implementation conditions
shared buffer use on something else, like initializing locale support.
Implementations usually document the choices they make when a standard
interface provides them an option. But that is typically done in
human-readable documentation.
I've been trying to curate a small database (unstructured) of thread-safety
and other portability issues by analyzing libc source code and
documentation, but in the case of musl I can't query my database because I
can't know whether musl is being used, let alone the version. Except,
perhaps, by process of elimination, or inspecting the toolchain directly.
I suppose my next step should be to try to turn by collected information on
portability problems into a structured database of some sort. Then that
would be a starting point for discussing the possiblity of defining a libc
API that communicates features and semantics.
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.
