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

Reply via email to