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

[Rich Felker <dalias at libc dot org>]

On Tue, Feb 17, 2015 at 01:38:37PM -0500, Zack Weinberg wrote:
> On 02/15/2015 11:03 AM, Rich Felker 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:
> >>>> 
> >>>> 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.
> 
> I really do not see this as an implementation bug.  I see this as a
> _spec_ bug.  POSIX.1b failed to foresee that putting a bare 'long' field
> in a structure passed in and out of the kernel by reference would cause
> problems for implementations that want to support LP64 and ILP32 ABIs on
> the same kernel.  ISO C picked up the structure definition verbatim
> without noticing that there was a problem. (Do you honestly think ISO C
> wouldn't have copied over a hypothetical nseconds_t if it had already
> been there in POSIX?)

I think it would have made the timespec struct less attractive for
adoption to begin with, which probably would have left us with yes
another gratuitous incompatible duplication between C and POSIX...

> ....
> > How is this a "sufficiently egregious case"? It's ONE 
> > essentially-unused configuration of ONE implementation where 
> > implementors failed to read the spec.
> 
> If you go back and look at the discussion on l-k, they (specifically,
> HJ, H. Peter Anvin, and Linus, if I understand correctly) _did_ read the
> spec and they decided it was wrong.

As far as I can tell, what they decided was wrong was the other stupid
topic they got derailed on -- the thing about "compilation
environments" and requiring the existence of at least one where
certain types have rank <= long. This is unrelated to the hard
requirement that tv_nsec be long, which they seem to have mysteriously
stopped discussing at that point after going on a rant about how
POSIX's requirements (these other unrelated ones) are unreasonable.

> (from yr reply to HJ):
> > There will never be more than 1000000000 nanoseconds in a second, and
> > LONG_MAX is necessarily larger than 1000000000. Forcing all programs
> > that are printing tv_nsec with %ld to change to %jd and cast the
> > argument to (intmax_t) is not reasonable.
> 
> I sympathize somewhat with this argument, although I expect the
> overwhelming majority of programs print tv_nsec by converting it to
> _double_ for ease of combination with tv_sec.
> 
> However, it can be dealt with by appropriate requirements on the
> underlying type:

We have people who are working on fixing this problem. I'm not going
to keep wasting time discussing proposals to enshrine this bug. Let
the people working on fixing it do their work.

Rich