-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not #undef __STRICT_ANSI__ #2059
Comments
I don't think this workaround is even used anymore. Removed in e737672, thanks for reporting. |
Undefining this macro makes GCC in standards C++ mode very unhappy: In file included from D:/msys64/ucrt64/include/c++/13.2.0/bits/requires_hosted.h:31, from D:/msys64/ucrt64/include/c++/13.2.0/string:38, from ..\subprojects\webrtc-audio-processing\webrtc/rtc_base/system/file_wrapper.h:17, from ../subprojects/webrtc-audio-processing/webrtc/rtc_base/system/file_wrapper.cc:11: D:/msys64/ucrt64/include/c++/13.2.0/x86_64-w64-mingw32/bits/c++config.h:666:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp] 666 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" | ^~~~~~~ See: fmtlib/fmt#2059 (comment) See: #32
Any chance to get it backported to 4.x branch or is it no longer supported? fmt 4.1.0 stopped building after updating gcc to 14.1.0 (and my project has to also build with RVCT 4.1 and gcc 4.4.1, so I'm stuck on that branch and 15 years in the past 😭):
|
fmt 4.x is not actively maintained but a PR to branch 4.x would be welcome. |
Backports fix from master branch as the code no longer compiles on mingw64/gcc 14.1.0 without gnu extensions enabled.
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++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>
isfalse
) 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.The text was updated successfully, but these errors were encountered: