Re: sign (in)consistency between architectures

[Rich Felker <dalias@aerifal.cx>]

On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote:
> On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote:
> > * Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:
> > > The current architecture-specific type definitions
> > > (arch/*/bits/alltypes.h) seem to entail the following inconsistent
> > > signed/unsigned types:
> > > 
> > > type      x86_64        i386
> > > -------------------------------
> > > uid_t     unsigned      signed
> > > gid_t     unsigned      signed
> > > dev_t     unsigned      signed
> > > clock_t   signed        unsigned
> > 
> > 
> > i can verify that glibc uses unsigned
> > uid_t,gid_t,dev_t and signed clock_t
> > 
> > of course applications should not depend on
> > the signedness, but if they appear in a c++
> > api then the difference can cause problems
> > 
> > and cock_t may be used in arithmetics where
> > signedness matters
> 
> uid_t, gid_t, and dev_t we can consider changing; I don't think it
> matters a whole lot and like you said they affect C++ ABI. clock_t
> cannot be changed without making the clock() function unusable. See
> glibc bug #13080 (WONTFIX):
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=13080

I just posted a followup on this bug: from what I can tell, it's
questionable whether having the return value of clock() wrap is
conforming even if clock_t is an unsigned type, and definitely
non-conforming if it's a signed type. As such, I see three possible
solutions:

1. Leave things along and do it the way musl does it now, where
subtracting (unsigned) results works. We should probably add a check
to see if the return value would be equal to (clock_t)-1, and if so,
either add or subtract 1, so that the caller does not interpret the
return value as an error.

2. Change clock_t to a signed type, and have clock() check for
overflow and permanently return -1 once the process has used more than
2147 seconds of cpu time. This seems undesirable to applications.

3. Change clock_t to long long on 32-bit targets. This would be
formally incompatible with the the glibc/LSB ABI, but in practice the
worst that would happen is that the register containing the upper bits
would get ignored.

Any opinions on the issue?

Rich