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

[Rich Felker <dalias at libc dot org>]

On Sun, Feb 15, 2015 at 10:30:56AM -0800, H.J. Lu wrote:
> On Sun, Feb 15, 2015 at 10:05 AM, Rich Felker <dalias@libc.org> wrote:
> > On Sun, Feb 15, 2015 at 10:02:23AM -0800, H.J. Lu wrote:
> >> On Sun, Feb 15, 2015 at 9:31 AM, Rich Felker <dalias@libc.org> wrote:
> >> > On Sun, Feb 15, 2015 at 08:27:33AM -0800, H.J. Lu wrote:
> >> >> 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?
> >> >
> >> > time_t is also a pain this way, but it's one of the few such types in
> >> > standard C. POSIX has a lot more that lack macros for their
> >> > printf/scanf specifiers and their min/max values: off_t, uid_t, etc.
> >> > They're of course necessary when you need to support historical
> >> > differences or when future systems may need a larger range of values
> >> > than a particular standard type provides, which is true for time_t.
> >> > It's not true for tv_nsec. 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.
> >> > It uglifies code and it's a huge burden to fix them all.
> >>
> >> We have done it for tv_sec:
> >>
> >> posix/tst-regex2.c:  printf (": %ld.%09lds\n", (long) stop.tv_sec,
> >> (long) stop.tv_nsec);
> >>
> >> and we should do  it for tv_nsec.  It works everywhere.
> >
> > We==who? Every single C programmer in the world should do this because
> > x32 has a bug? Note that the above isn't even correct; it assumes
> 
> It is a matter of opinion.

No, it's quite clear that C11 and POSIX both require tv_nsec to be
long. This is not an opinion. It's a statement of fact.

> > time_t fits in long, which is going to be false when ILP32 archs get
> 
> I am referring to casting on value with type time_t, like tv_sec.  You
> also need to do casting when printing tv_sec.

You do need to do it for tv_sec, and the only correct type to use
there is intmax_t. But you don't need to do it for tv_nsec, and this
is one of the practical benefits of the fact that the type for tv_nsec
is actually specified. It makes printfs much less ugly and reduces
code size (which busybox and similar apparently care about, though I
would say this is rather a useless microoptimization except in the
most extreme environments).

Rich