This:
causes undefined behaviour. That macro is for the implementation's use, not for yours. Changing it can lead to inconsistent state in libstdc++ headers, e.g. if somebody does this:
#include <type_traits>
#include <fmt/os.h>
#include <random>
If somebody compiles this snippet with -std=c++17 then __STRICT_ANSI__ will be defined when <type_traits> is included, so libstdc++ will define things in "strict" mode (e.g. is_integral_v<__int128> is false) and then the macro gets undefined, and then <random> defines things in "non-strict" mode, so it assumes it can use __int128 as a proper integer type. But it doesn't work, because of the earlier strict definitions in <type_traits>. You get confusing and nonsensical errors from libstdc++ headers.
Do not mess with this macro.
If your code is not compatible with __STRICT_ANSI__ then just tell users they need to use -std=gnu++17 not -std=c++17 so that __STRICT_ANSI__ isn't defined in the first place.
This:
fmt/include/fmt/os.h
Line 13 in 25a41b8
causes undefined behaviour. That macro is for the implementation's use, not for yours. Changing it can lead to inconsistent state in libstdc++ headers, e.g. if somebody does this:
If somebody compiles this snippet with
-std=c++17then__STRICT_ANSI__will be defined when<type_traits>is included, so libstdc++ will define things in "strict" mode (e.g.is_integral_v<__int128>isfalse) and then the macro gets undefined, and then<random>defines things in "non-strict" mode, so it assumes it can use__int128as a proper integer type. But it doesn't work, because of the earlier strict definitions in<type_traits>. You get confusing and nonsensical errors from libstdc++ headers.Do not mess with this macro.
If your code is not compatible with
__STRICT_ANSI__then just tell users they need to use-std=gnu++17not-std=c++17so that__STRICT_ANSI__isn't defined in the first place.