Am 01.05.2013 18:41, schrieb Rich Felker: > 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 [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 I consider the difference in sign to be of much greater significance, and therefore would prefer option #3. Besides, with enough patience and perseverance (/der lange Marsch durch die Institutionen.../), this might actually become the glibc solution as well:)