This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: statx struct's stx_size pointer compatibility with uint64_t/size_t
- From: Florian Weimer <fweimer at redhat dot com>
- To: Dominique Martinet <asmadeus at codewreck dot org>
- Cc: linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org, Quentin Bouget <quentin dot bouget at cea dot fr>, Jeff Layton <jlayton at kernel dot org>, David Howells <dhowells at redhat dot com>
- Date: Wed, 18 Dec 2019 12:51:26 +0100
- Subject: Re: statx struct's stx_size pointer compatibility with uint64_t/size_t
- References: <87r213aykv.fsf@oldenburg2.str.redhat.com> <20191217152154.GB25518@nautica> <20191217165350.GA10729@nautica>
* Dominique Martinet:
> This makes sense to me to avoid multiplying header files for the
> different arches, so if anything I would be tempted to ask 'why is
> stdint.h uint64_t defined with just long'?
It's not a compiler-provided header. When it was added to glibc in the
90s, I don't think long long support was universal among 64-bit
compilers, and you could not just drop the type (which might have been
acceptable on 32-bit architectures).
Anyway, looking at this, it looks like we should define struct statx
with unsigned long long int in our copy instead of uint64_t. I filed
bug 25292 to track this. I guess it's just another thing to keep in
mind when adding system call support to glibc headers.
Thanks,
Florian