Date: Wed, 1 May 2013 18:41:32 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: sign (in)consistency between architectures 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@...rvices.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.