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 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
time_t fits in long, which is going to be false when ILP32 archs get
64-bit time_t. In any case you're not going to have success getting
the word out to everybody that they "need to" change their code, and
they shouldn't have to. An O(1) fix (x32) is superior to an O(n) fix
(every singe C program in the world).

Rich


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