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.
