https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Karen from comment #8)
> Thanks for the explanation.
>
> In fact it doesn't work even for -D_XOPEN_SOURCE=700 as the latest POSIX
> edition doesn't specify the aligned_alloc function.
But it is defined by C11 and C++17, so if you compile with -std=c11 or
-std=c++17 (which will set __STDC_VERSION or __cplusplus respectively) then the
OS should declare aligned_alloc.
> On the other hand I don't observe that _XOPEN_SOURCE affects the __cplusplus
> macro:
I didn't say it changes the value of it, I said it overrides it. Look in
<malloc/_malloc.h> where the declaration of aligned_alloc is guarded by:
#if (__DARWIN_C_LEVEL >= __DARWIN_C_FULL) && \
((defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \
(defined(__cplusplus) && __cplusplus >= 201703L))
This means if _DARWIN_C_LEVEL is below "full" (which happens when
_XOPENS_SOURCE is defined) then aligned_alloc will never be declared, even when
the C or C++ language dialect requires it.
In my not so humble opinion that first && should be || instead, so that
aligned_alloc is declared if the level is "full" or greater, **or** if it's
required by the language standard that is in use.
> One can argue, but this can be considered a libstdc++ issue that it is
> affected by the macro that defines the C functions availability.
But you get exactly the same problem compiling this C program with -std=c11,
where libstdc++ is completely irrelevant and there are no GCC headers used:
#define _XOPEN_SOURCE 600
#include <stdlib.h>
int main() { free(aligned_alloc(4, 4)); }
This warns about aligned_alloc being implicitly declared, because the macOS
header fails to declare it.
This is an Apple bug, please report it to radar.
