[Bug libstdc++/100128] New: Behavior and performance depends on order of ctype.h and stdlib.h include

[Bug libstdc++/100128] New: Behavior and performance depends on order of ctype.h and stdlib.h include

[travis.downs at gmail dot com]

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

[Bug libstdc++/100128] Behavior and performance depends on order of ctype.h and stdlib.h include

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Travis Downs from comment #0)
> 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.

I think that's the only one.

Glibc should probably act as though __NO_CTYPE is implicitly defined by
__cplusplus, so that the effect is independent of the order of includes.

Alternatively, libstdc++ could add its own <ctype.h> wrapper to ensure that we
always include os_defines.h before the libc <ctype.h>.

[Bug libstdc++/100128] Behavior and performance depends on order of ctype.h and stdlib.h include

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Glibc should probably act as though __NO_CTYPE is implicitly defined by
> __cplusplus, so that the effect is independent of the order of includes.

Or it should define the ctype functions as C++ inline functions (without macros
hiding their names) so they can still be inlined.

[Bug libstdc++/100128] Behavior and performance depends on order of ctype.h and stdlib.h include

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-04-22
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Alternatively, libstdc++ could add its own <ctype.h> wrapper to ensure that
> we always include os_defines.h before the libc <ctype.h>.

Hmm, we already have this, but it's not installed.