From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3273 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sign (in)consistency between architectures Date: Wed, 1 May 2013 18:41:32 -0400 Message-ID: <20130501224132.GN20323@brightrain.aerifal.cx> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367448105 1765 80.91.229.3 (1 May 2013 22:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 May 2013 22:41:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3277-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 00:41:46 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UXfib-00005L-KG for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 00:41:45 +0200 Original-Received: (qmail 8177 invoked by uid 550); 1 May 2013 22:41:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8164 invoked from network); 1 May 2013 22:41:44 -0000 Content-Disposition: inline In-Reply-To: <20130501200007.GM20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3273 Archived-At: 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