[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

redi at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Jan 30 11:06:00 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2020-01-27 00:00:00         |2020-01-30
     Ever confirmed|0                           |1

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Another interpretation would be that it's simply user error to request a
specific POSIX version and an incompatible C standard. If POSIX:2008 doesn't
define things that C11 requires, you can't combine POSIX:2008 and C11.

And POSIX doesn't define what *anything* means for a C++ program, so arguably
using _XOPEN_SOURCE at all in C++ is undefined. If your POSIX implementation
gives it a useful meaning, great, but if not and the macro breaks your C++
code, don't define the macro.

Either way, how the OS interprets and responds to macros like _XOPEN_SOURCE is
out of libstdc++'s hands. If the OS decides that _XOPEN_SOURCE=600 and C++17
are incompatible, there's only so much libstdc++ can do. Something like this
should work though:

#if __cplusplus >= 201703L && defined(_GLIBCXX_HAVE_ALIGNED_ALLOC)
# if defined __APPLE__ && defined _XOPEN_VERSION
  // see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469
  extern "C" void* aligned_alloc(size_t, size_t);
# else
  using ::aligned_alloc;
# endif
#endif

Confirming as a bug, because we'll need that for previous releases of macOS
anyway, but please do report this to Apple too.


More information about the Gcc-bugs mailing list