-DGCDEBUG=1 is incompatible with -D_POSIX_C_SOURCE=200112L

[jpco]

Seems there is some better standards-compliance that can be done in gc.c. I wonder if we could get rid of the big __MACH__ block while we do.

[memreflect]

__MACH__ was used for any OS based upon the Mach microkernel, which meant mostly NeXT boxes back in the day.
Since the first release of OS X, the XNU kernel for macOS, iOS, Darwin, etc. inherited a lot of NeXT stuff, and the GNU Hurd fork of glibc also can use that code.
That said, both of them can also just use the POSIX code, so i'm fairly certain there's really no need for __MACH__ anymore.

As for the standards compliance issues unrelated to __MACH__, the nonstandard caddr_t type returned by mmap() on old systems appears to be the only barrier to compiling gc.c with -DGCDEBUG=1 -ansi -D_POSIX_C_SOURCE=200112L on Linux.
On POSIX systems that support mmap(), mmap() returns void * instead of caddr_t.

Speaking of POSIX, mmap() is only required for XSI conformance in POSIX.1-2001, meaning it's optional on non-XSI systems, and memory protection with mprotect() is also optional and independent of mmap().
In short, a POSIX.1-2001 system could have neither, one, or both of the functions.
POSIX.1-2008 requires both functions even on non-XSI systems.
Either both functions need to be required by a configure test—if either is missing, configure should fail—or es needs to assume a POSIX.1-2008 environment at minimum.

Lastly, MAP_ANONYMOUS may be named MAP_ANON, so it may be worth defining MAP_ANONYMOUS in terms of MAP_ANON if MAP_ANONYMOUS is not already defined.
POSIX.1-2024 defines both, so this shouldn't be an issue 5-10 years from now.

[jpco]

Sounds like my hope to have a strictly POSIX.1-2001-compliant GCDEBUG es is unlikely to happen. However, simplifying down to what you propose here is probably still valuable for code simplicity in terms of "#ifdef considered harmful"