On 1/4/21 6:29 PM, Bruno Haible wrote:
I want the files to be identical (eventually), which is why they have
the same include guard.
If they have the same include guard, then
Having the same include guard was merely a (wrong) means to the goal.
The goal is for the files to be identical. They can be identical while
using different include guards, and there should be some way to arrange
for that since in Gnulib cdefs.h should be included only from
libc-config.h and libc-config.h must be included first.
2. We are in trouble if glibc renames some internal macros of this
file. For example, if in glibc version 2.32 you have a macro __LDBL_FOO
and in glibc 2.33 this macro is renamed to __LBDL_FOOBAR, and another
macro is introduced with the old name __LDBL_FOO, we're in trouble,
because we cannot ship a single file that works both for installed
headers of glibc 2.32 and 2.33.
3. If some distributor (Red Hat, SuSE, etc.) makes local changes to this
file in glibc (and corresponding changes in e.g. /usr/include/stdio.h),
we are in trouble as well.
I don't see how switching included guards affects (2) and (3). For
example, even with switched include guards, doesn't Gnulib libc-config.h
redefine __LDBL_REDIR?
cdefs.h matches glibc closely to encourage current and future
integration of glibc and Gnulib, so it's not a great harm if we need to
continue to keep Gnulib cdefs.h up-to-date with glibc.