This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [glibc] <sys/stat.h>: Use Linux UAPI header for statx if available and useful
On 12/06/2019 16:26, Florian Weimer wrote:
> * Zack Weinberg:
>> On Wed, Jun 12, 2019 at 10:16 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> +#if __glibc_has_include (<linux/stat.h>)
>> ...
>>>
>>> It turns out that this does not work as expected in some configurations
>>> because linux is a macro, defined to 1, and it's expanded in this
>>> context
>>
>> I wonder how much stuff still depends on these legacy user-namespace
>> OS-specific macros. Would anyone even notice if we put
>>
>> #undef linux
>> #undef unix
>>
>> at the top of features.h? The GCC manual has said "We are slowly
>> phasing out all predefined macros which are outside the reserved
>> namespace" [1] since, um, 2001 give or take? but I don't think anyone
>> has ever done any actual work on getting rid of them :-/
>
> It's a bit drastic for this change. I want to backport it (at last
> downstream), after all.
gcc should first start poisoning all uses of these macros.
then a release later remove them.
>
>>> Is there a way to inhibit macro expansion in this context? Maybe with
>>> token pasting?
>>
>> The easiest thing that comes to mind is to write __glibc_has_include
>> ("linux/stat.h") instead. Then the preprocessor would see the argument
>> as a string literal and not expand "linux", and there shouldn't be a
>> /usr/include/sys/linux/stat.h ever, so it would come out equivalently.
>> Well, I guess someone could be using -iquote, but do we really need to
>> support the situation where someone pointed -iquote at a directory
>> containing a linux/stat.h, and at the same time there's no
>> linux/stat.h in the <> search path?
>
> Would that approach be acceptable? Then let's use that.
>
> It also avoids the same problem for the stat token.
>
> Alternatively, we would have to use something like this:
ouch, use the ""
(clang __has_include seems not to expand)