On Tue, Apr 13, 2021 at 09:06:12PM +0200, Mark Kettenis wrote: > > Date: Tue, 13 Apr 2021 19:36:26 +0200 > > From: Rafael Sadowski <raf...@sizeofvoid.org> > > > > Based on my cmake pull-request(1) to fix the cmake build on OpenBSD, the > > following question has arisen which is worth analysing? > > > > "It seems OpenBSD has a strange behavior because macro _POSIX_C_SOURCE is a > > standard! @sizeofvoid What are the errors raised if _POSIX_C_SOURCE or > > _XOPEN_SOURCE are defined?" -- Marc Chevrier > > > > [1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6000 > > > > The following code includes the if-defs from cmake with a simple sstream > > include. > > > > $ cat define_test.cxx > > #if !defined(_WIN32) && !defined(__sun) > > // POSIX APIs are needed > > // NOLINTNEXTLINE(bugprone-reserved-identifier) > > # define _POSIX_C_SOURCE 200809L > > #endif > > #if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__NetBSD__) > > // For isascii > > // NOLINTNEXTLINE(bugprone-reserved-identifier) > > # define _XOPEN_SOURCE 700 > > #endif > > > > #include <sstream> > > int main () { return 0; } > > > > $ clang++ -std=c++17 define_test.cxx # also with c++11/14 > > In file included from define_test.cxx:16: > > In file included from /usr/include/c++/v1/sstream:173: > > In file included from /usr/include/c++/v1/ostream:140: > > In file included from /usr/include/c++/v1/locale:207: > > /usr/include/c++/v1/__bsd_locale_fallbacks.h:122:17: error: use of > > undeclared identifier 'vasprintf'; did you mean 'vsprintf'? > > int __res = vasprintf(__s, __format, __va); > > ^ > > /usr/include/c++/v1/cstdio:124:9: note: 'vsprintf' declared here > > using ::vsprintf; > > ^ > > In file included from define_test.cxx:16: > > In file included from /usr/include/c++/v1/sstream:173: > > In file included from /usr/include/c++/v1/ostream:140: > > In file included from /usr/include/c++/v1/locale:207: > > /usr/include/c++/v1/__bsd_locale_fallbacks.h:122:27: error: cannot > > initialize a parameter of type 'char *' with an lvalue of type 'char **' > > int __res = vasprintf(__s, __format, __va); > > ^~~ > > /usr/include/stdio.h:269:21: note: passing argument to parameter here > > int vsprintf(char *, const char *, __va_list); > > ^ > > 2 errors generated > > > > Looks like, if "_XOPEN_SOURCE 700" or "_POSIX_C_SOURCE 200809L" is defined > > we > > run in this compile error. The question is, is that deliberate? > > This is a libc++ issue that isn't really OpenBSD-specific. It would > happen on Linux as well if you use libc++. > > To fix this we need to implement <xlocale.h>. > > That said, OpenBSD provides the POSIX APIs by default. I believe > FreeBSD and NetBSD don't. So your proposed fix makes sense.
FreeBSD, NetBSD, and macOS also have a default environment that exposes all APIs, modulo any conflicting prototypes.[1] It's been this way for at least 10 years. Ditto for DragonflyBSD and even Minix, IIRC. It's only AIX (_ALL_SOURCE), Solaris (__EXTENSIONS__), and Linux/glibc (_GNU_SOURCE, _DEFAULT_SOURCE) that require explicitly exposing a complete "native" environment. I'm not even sure about AIX (my Lua Unix module doesn't bother setting it), but I can't access my AIX dev shell at the moment. IME, fiddling with _XOPEN_SOURCE, _POSIX_C_SOURCE, or similar is not only unnecessary, but it *creates* more headaches. On most systems they're effectively *subtractive*, not additive. Once you explicitly specify a standard you enter portability hell as there's no consistent way to then make visible other APIs--many of which are de facto standard and universally available--that most programs invariably use. IOW, it's only when you specify a standard that you end up maintaining a nightmarish preprocessor feature flag ladder. [1] glibc's strerror_r is the only example I can think of where a default native environment exposes patently POSIX-incompatible types.
