<sys/stat.h>: Use Linux UAPI header for statx if available and useful

  * 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.

>> 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:


But this is a bit iffy because there's no guarantee that linux == 1.

Thanks,
Florian
  

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)