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 11:23 PM, Rich Felker <dalias@libc.org> wrote:
> 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,

If you don't consider this very thread to demonstrate adequate reason
for the type of tv_nsec to be abstract, then there's probably no point
me arguing it with you any further, but ...

> having it be abstract creates all sorts of additional problems.

Please state exactly what those problems are.

> In any case ISO C DR's do not move fast

Too bad for ISO C then.  In sufficiently egregious cases, - and yes, I
do think this qualifies - implementors can and should declare the
standard to be buggy and apply corrections ahead of the process.

zw


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