[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150305083315.GW1264@example.net>
Date: Thu, 5 Mar 2015 09:33:15 +0100
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
Subject: Re: MUSL Feature Detection
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.
Any "feature-collection" flag like "this is a certain implementation of
libc" is extremely volatile, as the corresponding "feature collection"
varies with every minor release. There is no contract/promise of keeping
the implementation details, which is actually the supposed isolation
property of APIs.
You are not expected to rely on anything not specified in the API -
but this seems to be what you are asking for.
Thus there can be no reliable predefined macro. Nor can there be a proper
build time feature check (unless you assume that the build result is to
be run in the exact environment of the build). I can regrettably hardly
imagine a reliable runtime check for thread safety either.
If you really feel that a check for "musl" is meaningful, then let
the person building your library specify this explicitly. If the person
does not know, you can not do better than unreliably guess or otherwise
avoid such assumptions. The choice is yours.
Sorry if I sound negative, I have full respect for your practical needs
but I doubt that they can be met in the way you wish.
Rune
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.
