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.