On Mar 5, 2015 3:58 AM, <u-wsnj@aetey.se> wrote:
>
> On Thu, Mar 05, 2015 at 09:33:15AM +0100, u-wsnj@aetey.se wrote:
> > On Wed, Mar 04, 2015 at 12:54:58PM -0800, William Ahern wrote:
> > > So, is there any sort of sanctioned way to detect MUSL at all,
version or no
> > > version? Is there any interest in supporting any kind of feature
detection,
> > > such as an API that communicates implementation choices wrt
unspecified and
> > > undefined behavior.
>
> Sorry for having made a too large citation.
>
> To be clear, I commented only on the part:
>
> > > So, is there any sort of sanctioned way to detect MUSL at all,
version or no
> > > version?
>
> [skipping my former message]
>
> As for your proposal
>
> > > 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?

Thanks
Stephen