This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv3 00/24] ILP32 support in ARM64
- From: Rich Felker <dalias at libc dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Zack Weinberg <zackw at panix dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 15 Feb 2015 12:31:55 -0500
- Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
- Authentication-results: sourceware.org; auth=none
- References: <CAKCAbMiQh2DVjgB_-By8FN2VN01_BkEoVJQunJ9KhWdYM8wJOw at mail dot gmail dot com> <20150215042302 dot GN23507 at brightrain dot aerifal dot cx> <CAKCAbMi8xZ8x3ECwus2LTvaurA66TLA38KgpOj=cAp7k3UwYvQ at mail dot gmail dot com> <20150215160330 dot GP23507 at brightrain dot aerifal dot cx> <CAMe9rOqQM04Lr_RMUBsvA-Y502UQDzXszXA8BUEdsHwZdpRRrA at mail dot gmail dot com>
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 <firstname.lastname@example.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 <email@example.com> 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.