From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3275 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 22:47:53 -0400 Message-ID: <20130502024753.GO20323@brightrain.aerifal.cx> References: <51814B3F.4040005@eservices.virginia.edu> <20130501180015.GN12689@port70.net> <20130501200007.GM20323@brightrain.aerifal.cx> <20130501224132.GN20323@brightrain.aerifal.cx> <5181C3B4.4040801@eservices.virginia.edu> 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 1367462888 3183 80.91.229.3 (2 May 2013 02:48:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 02:48:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3279-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 02 04:48:08 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 1UXjZ1-0003He-3L for gllmg-musl@plane.gmane.org; Thu, 02 May 2013 04:48:07 +0200 Original-Received: (qmail 31907 invoked by uid 550); 2 May 2013 02:48:06 -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 31896 invoked from network); 2 May 2013 02:48:05 -0000 Content-Disposition: inline In-Reply-To: <5181C3B4.4040801@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3275 Archived-At: On Wed, May 01, 2013 at 09:39:00PM -0400, Z. Gilboa wrote: > 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:) Well, the current text of POSIX acknowledges in the Application Usage text that, on some implementations, the return value of clock() wraps. Moreover, it mentions wrapping after 2147 seconds, which would be the signed wrapping point, but not whether the wrapping is to INT_MIN or to 0. It's hard to say which is worse; wrapping to INT_MIN gives you UB (integer overflow) when you subtract INT_MIN-INT_MAX, but in the real world you probably get the value you wanted, 1. Wrapping to 0 on the other hand would give you a gigantic difference when the clock wraps. Still, I see no acknowledgement that it might wrap in the ISO C definition for clock(), so it's possible that an interpretation would declare the wrapping non-conforming. In any case, I think all of these issues are good arguments that nobodu should ever use clock_t or the clock() function... Rich