Re:How to Write Portable C Without Complicating Your Build
by wahern on Friday March 31, 2017 @12:54PM
(#14005670)
If you’re coding to POSIX, you must define the
_POSIX_C_SOURCE feature test macro to the standard you
intend to use prior to any system header includes:
Nooooooo.....
Take it from someone who religiously keeps many of his very complex libraries portable across many systems (AIX, FreeBSD, Linux/glibc, Linux/musl, NetBSD, OpenBSD, Solaris, and others), the _last_ thing you want to do is define the POSIX portability macros.
Once you do that, you're in for a _world_ of hurt trying to use any extension, including routines from newer POSIX standards that are almost universally supported, but because some systems don't claim 100% compliance to the latest POSIX release, become hidden once you start using the user-definable feature macros.
Most systems (particularly the BSDs) make _everything_ available by default. On Linux, however, you should define _GNU_SOURCE; on Solaris, define __EXTENSIONS__ and _POSIX_PTHREAD_SEMANTICS; on AIX define _ALL_SOURCE; on Minix define _MINIX. This way, anything you might possibly want to use is available.
There are a few cases where a native extension conflicts with a POSIX routine. The classic case is strerror_r on glibc. Dealing with these cases is easier to deal with than fumbling with feature macros.
Remember, you'll _always_ want to use extensions unless you're writing pure ANSI C (C90) code. Portable is not the same thing as POSIX compliant. And many POSIX routines are effectively extensions on systems not yet certified for the latest POSIX standard.
Take it from someone who religiously keeps many of his very complex libraries portable across many systems (AIX, FreeBSD, Linux/glibc, Linux/musl, NetBSD, OpenBSD, Solaris, and others), the _last_ thing you want to do is define the POSIX portability macros.
Once you do that, you're in for a _world_ of hurt trying to use any extension, including routines from newer POSIX standards that are almost universally supported, but because some systems don't claim 100% compliance to the latest POSIX release, become hidden once you start using the user-definable feature macros.
Most systems (particularly the BSDs) make _everything_ available by default. On Linux, however, you should define _GNU_SOURCE; on Solaris, define __EXTENSIONS__ and _POSIX_PTHREAD_SEMANTICS; on AIX define _ALL_SOURCE; on Minix define _MINIX. This way, anything you might possibly want to use is available.
There are a few cases where a native extension conflicts with a POSIX routine. The classic case is strerror_r on glibc. Dealing with these cases is easier to deal with than fumbling with feature macros.
Remember, you'll _always_ want to use extensions unless you're writing pure ANSI C (C90) code. Portable is not the same thing as POSIX compliant. And many POSIX routines are effectively extensions on systems not yet certified for the latest POSIX standard.