mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: sign (in)consistency between architectures
Date: Wed, 1 May 2013 22:47:53 -0400	[thread overview]
Message-ID: <20130502024753.GO20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <5181C3B4.4040801@eservices.virginia.edu>

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


  reply	other threads:[~2013-05-02  2:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01 17:05 Z. Gilboa
2013-05-01 18:00 ` Szabolcs Nagy
2013-05-01 20:00   ` Rich Felker
2013-05-01 22:41     ` Rich Felker
2013-05-02  1:39       ` Z. Gilboa
2013-05-02  2:47         ` Rich Felker [this message]
2013-05-02  8:12           ` Jens Gustedt
2013-05-02 10:13             ` Szabolcs Nagy
2013-05-02 12:12               ` Jens Gustedt
2013-05-02 13:08                 ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130502024753.GO20323@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).