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

[Rich Felker <dalias at libc dot org>]

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.

> > 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.

How is this a "sufficiently egregious case"? It's ONE
essentially-unused configuration of ONE implementation where
implementors failed to read the spec. It's not the responsibility of
standards to clean up their messes for them. Abstract types to make up
for things like this (think: the hideous socklen_t that was added
because different historical implementations disagreed whether the
socket functions take size_t or int) have a place when there's
existing historical practice, from before the interface was
standardized, that the standard needs to account for, not when someone
just fails to read the existing spec and demands a retroactive
relaxation to accommodate laziness.

Rich