Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 8 Feb 2013 15:19:30 -0500
From: Rich Felker <>
Subject: Re: musl detection by preprocessor

On Fri, Feb 08, 2013 at 09:12:16PM +0100, Jens Gustedt wrote:
> > I'm not sure how you can determine with just the standard macros that
> > you're on a POSIX or POSIX-like system where you have unistd.h...
> Sure, usually you have to provide that information on the commandline
> or through extensions (such as -std=gnu99). On POSIX systems you have
> the getconf tool that provides reliable information about the
> system:
> getconf _POSIX_VERSION
> should always work.

If you're on a system that has a shell, command line utilities, and
makefiles, it almost certainly has unistd.h, in which case including
unistd.h can tell you about which standards it supports.

> I probably have to review my include ordering a bit, currently I
> set __GNUC_SOURCE *before* including unistd.h. I understood from their
> docs that this is the way it is meant to be. Only by having it defined
> before, I will in fact see the extensions they provide.

Yes. The _*_SOURCE macros (called feature test macros, a rather
confusing name) are meant to be defined by the application to request
a particular featureset or conformance profile from the
implementation. Note that the standards require them to be defined
before _any_ system header is included, since it's possible (as in
glibc and its features.h) that they're processed only once, at the
time of the first inclusion of a system header. But it's also possible
that they're processed at the time of each header's inclusion. The
only portable way to use them is to define them before including any
system headers.


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.