bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]