From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7147 Path: news.gmane.org!not-for-mail From: u-wsnj@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: MUSL Feature Detection Date: Thu, 5 Mar 2015 09:33:15 +0100 Message-ID: <20150305083315.GW1264@example.net> References: <20150304205458.GA14554@wilbur.25thandClement.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1425544448 25488 80.91.229.3 (5 Mar 2015 08:34:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 08:34:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7160-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 05 09:34:04 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YTRE9-0004qf-2J for gllmg-musl@m.gmane.org; Thu, 05 Mar 2015 09:33:53 +0100 Original-Received: (qmail 11705 invoked by uid 550); 5 Mar 2015 08:33:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11668 invoked from network); 5 Mar 2015 08:33:47 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe08.swip.net; client-ip=178.63.97.34; envelope-from=u-wsnj@aetey.se Content-Disposition: inline In-Reply-To: <20150304205458.GA14554@wilbur.25thandClement.com> Xref: news.gmane.org gmane.linux.lib.musl.general:7147 Archived-At: 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