[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: glibc and cdefs.h
From: |
Bruno Haible |
Subject: |
Re: glibc and cdefs.h |
Date: |
Sun, 24 Jun 2018 18:44:33 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-128-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
> I would like to keep Gnulib cdefs.h in sync with glibc as much as
> possible, and installed the attached.
The __nonnull handling here is more risky than my patch. But it works on
FreeBSD 11.
> I hope this sort of thing is a one-off.
>
> I guess you're suggesting two include files? config.h has to come first, so
> there'd be another include file (let's say, configlast.h) that would come
> last.
> I think something like that would work, though it would complicate the
> shared-with-glibc files a bit more, and even then it wouldn't be 100%
> reliable
> because system include files could define macros that are expanded after
> configlast.h is included.
>
> If this is the only such problem we run into I'm not sure it's worth the
> hassle
> of having multiple includes. If we run into more such problems, we can keep
> this
> idea in reserve, though.
I would find it more reliable to just stay away from using symbols that start
with '__', because that is the "implementation's" namespace, i.e. partially the
operating system's namespace and partially the compiler's namespace. That is,
I would suggest to use symbols prefixed with '_GLIBC_' where glibc uses symbols
prefixed with '__'.
But I understand that this would make the sync with glibc more complicated
(although it could be automated: "sed -e 's/_GLIBC_/__/g'"), and you are doing
the work.
Bruno