From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7133 Path: news.gmane.org!not-for-mail From: William Ahern Newsgroups: gmane.linux.lib.musl.general Subject: MUSL Feature Detection Date: Wed, 4 Mar 2015 12:54:58 -0800 Message-ID: <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 1425502520 10673 80.91.229.3 (4 Mar 2015 20:55:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 20:55:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7146-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 04 21:55:19 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 1YTGK6-00065s-Tw for gllmg-musl@m.gmane.org; Wed, 04 Mar 2015 21:55:19 +0100 Original-Received: (qmail 1739 invoked by uid 550); 4 Mar 2015 20:55:17 -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 1688 invoked from network); 4 Mar 2015 20:55:11 -0000 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:7133 Archived-At: I'm familiar with the policy that MUSL is not interested in adding version macros, etc. I mostly agree with the policy, however there are some corner cases where it's problematic. I maintain a Lua bindings library to Unix APIs http://25thandclement.com/~william/projects/lunix.html Unlike the most commonly used module, luaposix, my module tries to be as thread-safe as possible. (It also supports "portable" but non-POSIX interfaces.) That means using all the re-entrant versions of functions if available. But some functions don't have re-entrant versions, such as strsignal. In those cases I try to synthesize a safe version if possible and practical, such as using sys_siglist if available. Knowing whether an interface is thread-safe requires me inspecting the code and basically documenting my findings inside the source code with conditionals. I could _also_ do run-time checks, but that's more susceptible to false negatives, and so I think it would only make sense to do that as a back-stop. (Compile-time checks won't work for cross-compiling). The vast majority of people don't pay attention to obscure thread-safety issues, especially because the most popular platforms like Linux/glibc and Solaris do a pretty decent job of implementing APIs in a thread-safe manner (e.g. getenv, strsignal). This lack of interest is especially true in the context of a library, and doubly so of a scripting module, where people just assume the mode and the dependencies do the right thing, assuming they bother worrying about it in the first place. So you can see I'm stuck between a rock and a hard place. MUSL is probably safe in most regards. It doesn't even do localization, so strsignal is safe. But I have no easy way to _know_ that I'm building against MUSL without the person compiling the module knowingly and explicitly changing the build configuration. 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.