Date: Tue, 26 Jan 2021 00:13:11 -0500 From: Garrett Wollman <wollman@csail.mit.edu> To: d@delphij.net Cc: freebsd-standards@freebsd.org Subject: _POSIX_C_SOURCE and S_IFMT macros Message-ID: <24591.42215.445286.330260@khavrinen.csail.mit.edu> In-Reply-To: <69977864-0a68-909d-8ecb-1d72c0ec0ef9@delphij.net> References: <69977864-0a68-909d-8ecb-1d72c0ec0ef9@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Mon, 25 Jan 2021 01:04:25 -0800, Xin Li via freebsd-standards <freebsd-standards@freebsd.org> said: > I recently discovered [1] a difference between FreeBSD's handling of > _POSIX_C_SOURCE and what I have observe on Linux and macOS systems, > basically, if a program defines _POSIX_C_SOURCE to 200809L, but did not > define _XOPEN_SOURCE, we will not define S_IFMT when sys/stat.h is included. We (try to[1]) take a "strict namespacing" policy: if an application asks for a strict POSIX environment, then we try not to define symbols other than those required by the standard to be present, even if they are permitted. In the case of the "X/Open System Interfaces" option, which we do not completely implement (and never have -- it mostly memorializes old System V mistakes that were never part of our BSD heritage), those symbols are only declared when _XOPEN_SOURCE is defined, which applications are required by the standard to define if they wish to use those interfaces. This is a different, less permissive approach than is taken by glibc, but it is intentional and it is permitted by the standard. Non-standard-conforming applications should not define a feature-test macro that requests a standard-conforming compilation environment. -GAWollman [1] I can't promise that we succeed. I know I didn't come close when I did a lot of namespace cleanliness work in the early 2000s, and I probably still have the bde-mail (RIP) to prove it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24591.42215.445286.330260>