Clang does not define `__STRICT_ANSI__` on Windows

[LIJI32]

Clang's documents explicitly specify that cXX modes, in contrast to gnuXX modes, define __STRICT_ANSI__. However, it does not seem to be the case on Windows.

Tested:

clang version 20.1.7
Target: x86_64-pc-windows-msvc
Thread model: posix

On macOS, running clang -std=c11 -Xclang -dM -E - < /dev/null and clang -std=gnu11 -Xclang -dM -E - < /dev/null produce a single line of difference – #define __STRICT_ANSI__ 1. On Windows, however, both have identical outputs; __STRICT_ANSI__ is never defined.

This makes it hard to detect the availability on GNU extensions in headers.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Lior Halphon (LIJI32)

Clang's documents explicitly specify that [`cXX` modes, in contrast to `gnuXX` modes, define `__STRICT_ANSI__`](https://github.com/llvm/llvm-project/blob/122afae10ed28564b64530de571ce8e4ce584b2c/clang/docs/UsersManual.rst#differences-between-various-standard-modes). However, it does not seem to be the case on Windows.

Tested:

clang version 20.1.7
Target: x86_64-pc-windows-msvc
Thread model: posix

On macOS, running clang -std=c11 -Xclang -dM -E - < /dev/null and clang -std=gnu11 -Xclang -dM -E - < /dev/null produce a single line of difference – #define __STRICT_ANSI__ 1. On Windows, however, both have identical outputs; __STRICT_ANSI__ is never defined.

This makes it hard to detect the availability on GNU extensions in headers.

[AaronBallman]

This is a bug in the documentation rather than a bug with the predefined macros in Clang. When compiling for an MSVC-compatible target (x86_64-pc-windows-msvc would be one, or when passing -fms-compatibility explicitly), we do not predefine __STRICT_ANSI__ because cl.exe doesn't, even in its strict conformance mode for C89: https://godbolt.org/z/YMc58dW3v

GCC's documentation is a bit better about describing __GNUC__ and __STRICT_ANSI__ meanings, but to determine whether GNU extensions are enabled, you should check for __GNUC__. In Clang, as in GCC, GNU extensions are always enabled. However, Clang does have the ability to explicitly set the value for __GNUC__ and setting it to 0 will cause __GNUC__ to not be defined; despite that, the GNU extensions are still enabled: https://godbolt.org/z/bnbTPjK3Y If you want to avoid use of extensions for portability reasons, you should pass -pedantic-errors or -pedantic -Werror, though this will disable all extensions, not just GNU extensions.

[LIJI32]

Yeah, I looked into the source later and realized the problem is the docs rather than Clang itself, but this behavior still makes it impossible to tell gnuXX and cXX apart.

In short: I develop a library that requires Clang or GCC in gnu11 mode (or newer). The header, while still requiring Clang or GCC, does not require any specific C standard. However, it still needs to check for the availability of GNU features. I specifically wanted to check for the availability of typeof. If __STRICT_ANSI__ is defined and using a C standard older than C23, I assume we don't have typeof available, and I define typeof to __typeof__. But when building on Windows with a non-Gnu standard, the lack of __STRICT_ANSI__ define makes impossible to tell the two modes apart, and I incorrectly detect C11 as GNU11.

[AaronBallman]

Would something along these lines suffice? https://godbolt.org/z/6ETcnjn9T

[firewave]

Having the GNU extensions enabled has further implications. It also enables _BSD_SOURCE, _POSIX_C_SOURCE and _LARGEFILE_SOURCE (not through the compiler but probably through the respective includes). Without them you have specify those manually. See danmar/cppcheck#7067 for changes I had to do when disabling the extensions.