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: [PATCHv3 00/24] ILP32 support in ARM64


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


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