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
- From: Florian Weimer <fweimer at redhat dot com>
- To: libc-alpha at sourceware dot org
- Cc: Carlos O'Donell <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Wed, 12 Jun 2019 16:16:30 +0200
- Subject: Re: [glibc] <sys/stat.h>: Use Linux UAPI header for statx if available and useful
- References: <20190612110504.66041.qmail@sourceware.org>
* Florian Weimer:
> +#if __glibc_has_include (<linux/stat.h>)
> +# include <linux/stat.h>
> +# ifdef STATX_TYPE
> +# define __statx_timestamp_defined 1
> +# define __statx_defined 1
> +# endif
> +#endif
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:
[pid 26516] openat(AT_FDCWD, "/usr/lib/gcc/x86_64-redhat-linux/8/include/1/stat.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 26516] openat(AT_FDCWD, "/usr/local/include/1/stat.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 26516] openat(AT_FDCWD, "/usr/include/1/stat.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
This also affects __has_include, so it's arguably a GCC bug. But with
__glibc_has_include, I think expansion is mandatory, so
__glibc_has_include can never really work in these configurations.
Is there a way to inhibit macro expansion in this context? Maybe with
token pasting?
Thanks,
Florian