mailing list of musl libc
 help / color / mirror / code / Atom feed
From: u-wsnj@aetey.se
To: musl@lists.openwall.com
Subject: Re: MUSL Feature Detection
Date: Thu, 5 Mar 2015 09:33:15 +0100	[thread overview]
Message-ID: <20150305083315.GW1264@example.net> (raw)
In-Reply-To: <20150304205458.GA14554@wilbur.25thandClement.com>

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



  parent reply	other threads:[~2015-03-05  8:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04 20:54 William Ahern
2015-03-05  4:23 ` Rich Felker
2015-03-05  8:33 ` u-wsnj [this message]
2015-03-05  8:58   ` u-wsnj
2015-03-05 15:34     ` stephen Turner
2015-03-05 21:02       ` William Ahern
2015-03-05 21:38         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150305083315.GW1264@example.net \
    --to=u-wsnj@aetey.se \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).