https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
Bug ID: 100128 Summary: Behavior and performance depends on order of ctype.h and stdlib.h include Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: travis.downs at gmail dot com Target Milestone: --- When ctype.h is included as the first header in a file, it will be processed without __NO_CTYPE being defined. This results in several differences versus the case where __NO_CTYPE is defined. For example, toupper() is defined as extern inline or as a macro if __NO_CTYPE is undefed, but is not defined (only declared), otherwise. As another example, is_alnum_l and many similar methods will be defined as macros if __NO_CTYPE is undefined, but otherwise will not. On the other hand, if you include stdlib.h (or many other files such as <algorithm>) in a C++ compile, the C++ "override" file include/c++/10.3.0/stdlib.h gets included, which ultimately ends up including x86_64-linux-gnu/bits/os_defines.h which defines __NO_CTYPE. If <ctype.h> is subsequently included, its effect is different as described above. I suppose this is an ODR violation in one way or another (e.g., if two files are included in the same program with and without __NO_CTYPE), and it can also have a significant impact on performance as described here: https://travisdowns.github.io/blog/2019/11/19/toupper.html Evidently, the behavior and definitions exposed by these headers should not depend on the order of include. I suspect there are other cases besides the __NO_CTYPE as long as files that don't trigger the C++ header include chain like ctype.h exist. You can play with this example on godbolt: https://godbolt.org/z/vY4EnE51z Try swapping the order of ctype and stdlib includes to see the effect. The int variables are canaries so you can see which macros were defined in the preprocessed output. This is the same as glibc bug #25214, but I was advised over there than this should be filed against libstdc++ instead. https://sourceware.org/bugzilla/show_bug.cgi?id=25214