[Bug libc/33120] New: interaction between _FORTIFY_SOURCE and clang modules

[lukeh at padl dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=33120

            Bug ID: 33120
           Summary: interaction between _FORTIFY_SOURCE and clang modules
           Product: glibc
           Version: 2.39
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: lukeh at padl dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

When using clang modules, ambient preprocessor definitions must match across
translation units that import them.

When _FORTIFY_SOURCE is enabled, realpath() (defined in <bits/stdlib.h>)
becomes an inline function whose definition depends on whether or not
<limits.h> has been imported.

This can cause confusing compilation errors if the order of including
<stdlib.h> and <limits.h> is not consistent between modules. [1]

Whilst I believe it's reasonable to require that ambient preprocessor
definitions such as (for example) _XOPEN_SOURCE are consistent, I don't believe
it's reasonable to mandate consistent ordered includes of standard library
headers.

I don't know enough about glibc to suggest a solution beyond possibly including
<limits.h> in <stdlib.h> if _FORTIFY_SOURCE is enabled (which I appreciate may
pollute the namespace).

[1] https://github.com/swiftlang/swift-testing/pull/1184

-- 
You are receiving this mail because:
You are on the CC list for the bug.