Re: [PATCHv3 00/24] ILP32 support in ARM64

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Feb 15, 2015 at 8:03 AM, Rich Felker <dalias@libc.org> wrote:
> On Sun, Feb 15, 2015 at 10:41:36AM -0500, Zack Weinberg wrote:
>> 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 ...
>
> Bugs in an implementation are not automatically a reason to change a
> specification. If you don't understand that there's probably no point
> in arguing with you.
>
>> > having it be abstract creates all sorts of additional problems.
>>
>> Please state exactly what those problems are.
>
> Lack of a proper format specifier/conversion specifier for use with
> printf/scanf family functions. Lack of clarity over which strto*
> function you should use with it. Etc.
>

How is it different from time_t?


-- 
H.J.