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: Wed, 6 Jan 2021 10:06:22 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 1/5/21 2:42 PM, Bruno Haible wrote:
2) Another possibility I can think of is to go through all the macros
defined by lib/cdefs.h, and for those which are actually used in Gnulib
(most aren't), provide fallback definitions in lib/libc-config.h.

Although that would solve the scenario you describe, it wouldn't solve the problem if glibc changed the meaning of __flexarr. (Admittedly this is less likely.)

the use of __THROW and __NTH in argp.h are already secured
by these fallbacks:

And those fallbacks wouldn't work if glibc changed the meaning of __THROW etc.

I think it unlikely that glibc will remove or modify the macros that Gnulib actually relies on without considerable notice. Most of the macros you listed (e.g., __ASMNAME) are private to Gnulib libc-config; we needn't worry about them because their removal from glibc wouldn't affect building program tarballs using an older Gnulib (as long as that Gnulib is no older than now). The remaining macros (e.g., __BEGIN_DECLS) are pretty stable. If we run into a problem with them we can adopt a more-drastic solution in the future, but I'm hoping we don't need to.

While looking through your list of macros I did see one glitch: __glibc_has_attribute. I plan to install a patch soon.

These fallbacks could be concentrated in libc-config.h, rather than
duplicating them in argp, fnmatch, glob, regex, obstack, etc.

It would be helpful if we arranged for argp etc. to use libc-config.h and so removed the need for those fallbacks in argp.h etc.; that would decrease the distance between them and glibc. This is true regardless of whether the fallbacks are in libc-config.h or in cdefs.h. I'll take a look into doing that.



reply via email to

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