This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] <sys/stat.h>: Use Linux kernel UAPI header if available and useful


* Andreas Schwab:

> On Jun 11 2019, Florian Weimer <fweimer@redhat.com> wrote:
>
>> This will need preprocessor hacks.
>
> Does it?

How else can we implement this?  We need to include both <linux/stat.h>
and <io/bits/statx-generic.h>, and as written, the two conflict.  And
outside of glibc, <io/bits/statx-generic.h> must define struct statx.

So we would have to add a macro that allows us to change the tag name of
the definition in <io/bits/statx-generic.h>, I think.

Alternative, we could compile statx_generic separately and directly
include <io/bits/statx-generic.h>, bypassing the sysdeps search path.
But that means we cannot include <sys/stat.h>, but we need it for the
AT_* constants.

In the meantime, I've looked at restricting the fields we write to in
statx_generic.  We need to write to what is padding today, due to the
way future extensions have been defined.  But if the kernel turns
padding into actual struct members, the code will fail to compile
because the member names are no longer correct.  If we want to avoid
that, we would have to zero-initialize *buf with a 256-byte memset, and
write only to the non-zero members with actual data.

I think we should duplicate the current definition in statx_generic, or
go with original approach (with the _Static_assert).

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]