Date: Wed, 4 Mar 2015 23:23:54 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: MUSL Feature Detection On Wed, Mar 04, 2015 at 12:54:58PM -0800, William Ahern wrote: > 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 Thanks for the background. I missed this in replying to your other message thread. > 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. FYI, musl's strerror and strsignal are always thread-safe. They return immutable strings which are valid for the entire lifetime of the program. > Knowing whether an interface is thread-safe requires me inspecting the code > and basically documenting my findings inside the source code with > conditionals. Thread-safety for all standard functions is documented by the standards. All functions defined in POSIX are thread-safe except those in the table in XSH 2.9.1: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01 C11 also specifies which functions are exempt from the requirement not to have data races, but there does not seem to be any official unified table; you have to look locally at the documentation for each. At some point in the future, musl's documentation will specify which non-standard functions are guaranteed to be thread-safe and which additional standard functions, beyond those required to be thread-safe, are guaranteed to be thread-safe in musl. I'm hoping to make progress on this documentation by the time of the 1.2.0 release. > 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). I don't think run-time checks are practical to deduce thread-safety. It could easily require months or years of hammering on an interface to demonstrate it non-thread-safe, and similar time scales to achieve reasonable certainty that a function is thread-safe. > 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. It does, and the localization is thread-safe. Both hard-coded English message strings and the translated messages (it any) are immutable. > 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. If we make any information available for programmatic use, I would like to coordinate this with at least one other libc implementation (which would probably be glibc, but BSDs are welcome to participate too). That way it becomes something of a cross-platform convention rather than our own local quirk. Rich
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.