This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: "Manuel A. Fernandez Montecelo" <manuel dot montezelo at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 6 Jun 2016 20:03:10 +0000
- Subject: Re: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?
- Authentication-results: sourceware.org; auth=none
- References: <20160606185149 dot GA11555 at reva dot itsari dot org> <20160606185423 dot GA12134 at reva dot itsari dot org> <CAKCAbMiRdHE7bV5=5mk3-rR6fTPdwasG9bhY-iGh7-zNQ8GxSg at mail dot gmail dot com>
On Mon, 6 Jun 2016, Zack Weinberg wrote:
> Shouldn't blkcnt_t, fsblkcnt_t, and fsfilcnt_t also get this
> treatment?
Yes, it would be desirable for struct {stat,statfs,statvfs} to match so
that relevant functions can be aliases. More *MATCHES* macros and
corresponding implementation would be needed to cause the functions to be
aliases, since much such aliasing is implemented through wordsize-64
sysdeps directories at present.
> (And anything else affected by -D_FILE_OFFSET_BITS=64 that
> I missed.) And, while we're at it, time_t?
For time_t, again, make sure to avoid the x32 mistake with a
non-POSIX-conforming type for nanoseconds (you can have endian-appropriate
explicit padding if you want to match a 64-bit ABI, but tv_nsec should
have type "long" and the kernel needs to ignore the padding on input).
--
Joseph S. Myers
joseph@codesourcery.com