Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h

[Bruno Haible]

Paul Eggert wrote:
> >> I want the files to be identical (eventually), which is why they have
> >> the same include guard.
> 
> 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

Yes, this is what I was hoping for. A simple s/_SYS_CDEFS_H/_GL_CDEFS_H/
command in your comparison scripts.

> >   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).

In Paul Murphy's case, a very new <stdio.h> from glibc was including
<sys/cdefs.h>, and since the macro _SYS_CDEFS_H was already defined (from
prior inclusion of libc-config.h -> cdefs.h), this include did nothing.
<stdio.h> then assumed a macro __LDBL_REDIR1_DECL but this macro was not
present.

> For example, even with switched include guards, doesn't Gnulib libc-config.h
> redefine __LDBL_REDIR?

Yes, there is the potential for redefinition warnings here. If they occur,
we should consider where in the compilation unit to include standard headers
like <stdio.h> and where to include <libc-config.h>. And maybe add a header
<libc-config-end.h> which undefines all of <libc-config.h> ?

Bruno