|
From: | Paul Eggert |
Subject: | Re: [PATCH] Merge glibc ieee128 ldbl redirect support into cdefs.h |
Date: | Mon, 4 Jan 2021 19:04:18 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |