> seemed to be correct.
> but perhaps i misunderstood
on second thought, i think i was just getting a delayed
fpe. sorry.
do you know why the fpe is delayed? so annoying.
- erik
>the implicit conversion on return also appears botched.
both this:
uint
fun(void)
{
double g;
g = 4215866817.;
USED(g);
return g;
}
void
main(void)
{
uint x;
double g;
x = fun();
USED(x);
g = 1.;
exits("");
}
and
> so getival returning uint or ulong (or unsigned something-big-enough) avoids
> the problem and seems fine to me.
good. i always get diff backwards. sorry.
i agree on the standard quite.
> there is, however, a bug in the compiler elsewhere, in that a suitable (uint)
> cast in a
> direct assig
oh! getival is yours? but it's in the changes on the - lines not the + lines.
the diffs have crossed the equator!
i think i understand now.
so the original had statements such as:
wc = (int)getfval(x);
and for excessive values in x (that couldn't be represented as an int)
there was
On Tue Dec 1 16:32:33 EST 2009, fors...@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
>
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
i applied the patch to my fresh port of the one true
awk: /n/sources/contrib/quanstro/src/awkupd
- erik
On Tue Dec 1 11:58:47 EST 2009, fors...@terzarima.net wrote:
> i hadn't noticed the changed example.
> it's removing the cast, which probably isn't right, although
> in that particular case it's probably better
> that it should trap (because the result is wrong).
> what is the actual code in awk t
i hadn't noticed the changed example.
it's removing the cast, which probably isn't right, although
in that particular case it's probably better
that it should trap (because the result is wrong).
what is the actual code in awk that's equivalent to that sequence?
alternatively, a sleep will kill the proc
since restoring the floating point will
trigger the latent trap.
- erik
#include
#include
void
main(void)
{
int x;
double g;
g = 4215866817.;
x = (uint)g;
USED(x);
g = 1.;
exits("");
}
#include
#include
void
main(void)
{
double g = 4215866817.;
print("%d\n", (unsigned int)g);
print("%d\n", (unsigned int)g);
exits("");
}
8c r.c
8l r.8
./8.out
-79100479
-79100479
no trap. it generates different code.
(obviously the %d should be %ud in this case,
On Tue Dec 1 04:40:09 EST 2009, fors...@terzarima.net wrote:
> g = 4215866817.;
> x = (int)g;
>
actually the target variable must be a uint. a cast still
traps. is the compiler wrong on this?
- erik
g = 4215866817.;
x = (int)g;
does g fit in (int)? (no, (int) is 32 bit signed.)
if (int) is (uint) it will fit, and not trap.
the fppc points to the offending instruction.
even more bare-bones version:
#include
#include
void
main(void)
{
int x;
double g;
g = 4215866817.;
x = (int)g;
g=1.;
USED(x);
exits("");
}
16 matches
Mail list logo
