[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130502024753.GO20323@brightrain.aerifal.cx>
Date: Wed, 1 May 2013 22:47:53 -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 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
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.
