This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv3 00/24] ILP32 support in ARM64
- From: Rich Felker <dalias at libc dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 14 Feb 2015 23:23:02 -0500
- Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
- Authentication-results: sourceware.org; auth=none
- References: <CAKCAbMiQh2DVjgB_-By8FN2VN01_BkEoVJQunJ9KhWdYM8wJOw at mail dot gmail dot com>
On Sat, Feb 14, 2015 at 02:18:15PM -0500, Zack Weinberg wrote:
> Joseph Myers wrote:
> > I believe I made clear in the discussion of 64-bit time interfaces for
> > 32-bit systems that the x32 ABI mistake was not one to be repeated - that
> > since there is obviously no need for nanoseconds values that cannot fit in
> > 32 bits, nanoseconds (and microseconds) values should remain as long in
> > accordance with POSIX.
>
> I have to say that I think tv_nsec (and tv_usec) being specified as
> bare 'long' is a spec bug _in and of itself_. The various *_t types
> exist precisely to make this sort of problem go away. As such, I am
> inclined to think that the _proper_ fix is to file DRs to that effect,
> and then invent 'nseconds_t' and use it. Unconditionally - not just
> for ILP32-on-64-bit-kernel.
POSIX does that nonsense, yes. ISO C, not so much. There's utterly no
reason for the type of tv_nsec to be abstract like this, and having it
be abstract creates all sorts of additional problems. In any case ISO
C DR's do not move fast, and it would be 5+ years before you would
have a "fix" for this non-issue on the C side and decades before
everyone would be using the new version of C. This is purely an
implementation bug that, so far, is isolated to x32, and it should not
be allowed to spread.
Rich