From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  1 Dec 2009 16:45:05 -0500
To: 9fans@9fans.net
Message-ID: <0ac7d411bce930a524248146c7150ada@ladd.quanstro.net>
In-Reply-To: <<0232aa110f8423b8381e009b6cda7cef@terzarima.net>>
References: <<0232aa110f8423b8381e009b6cda7cef@terzarima.net>>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] compiler double bug.
Topicbox-Message-UUID: a6777d90-ead5-11e9-9d60-3106f5b1d025

On Tue Dec  1 16:32:33 EST 2009, forsyth@terzarima.net wrote:
> those fixes really don't seem right to me. the problem is in getival
> or its callers. somewhere along the way, ULONG_MAX is converted to double
> and then back to int (directly or indirectly). that yields a trap. now, in the case
> 	int x;
> 	x = (uint)d;
> the compiler is wrong to eliminate the cast, but then again, if x isn't uint
> that's not going to work properly anyway (since x will go negative for big enough values of d).

i don't claim this is the best way to do this!

but getival does elimate the traps.  try it.  it is okay to pass ULONG_MAX
bac as a uint return value, isn't it?  i don't see the compiler doing the
wrong thing in this case.  and ULONG_MAX is an okay uint
value.  (probablly should have used UINT.)

since there are always numbers (42158668170.) that will trap
even if using uint (or even vlong), i don't see how to avoid doing
the comparison in floating point.

- erik