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
