Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> $ cat big.pasm
> new P0, .BigInt
> set P0, 18446744073709551615
> print P0
> print "\n"
> end
> $ ./parrot ~/big.pasm
> 9223372036854775807
> $
> This on a 64-bit system (tru64 alpha), substitute 4294967295 for the
> 18446744073709551615 in a 32-bit system.
> I don't know off-hand what would be The Right Thing here (I'm guessing
> that a signed long is used to hold the parsed constant, and that's why
> the "unsigned" constant overflows) -- but silent lossage / corruption of
> the PASM's intent is clearly not a right thing to do.
Yep. It's kind of a GIGO. 4294967295 isn't a valid 32 bit signed. The
program runs ok with
set P0, 4294967295L
but that should of course be detected. The C< atol() >s in imcc/pbc.c
are the culprit. This patch helps:
--- parrot/imcc/pbc.c Sat Jul 17 16:14:00 2004
+++ parrot-leo/imcc/pbc.c Sun Aug 1 11:12:44 2004
@@ -758,7 +758,9 @@
else if (r->name[0] == '0' && r->name[1] == 'b')
r->color = strtoul(r->name+2, 0, 2);
else
- r->color = atol(r->name);
+ r->color = strtol(r->name, 0, 10);
+ if (errno == ERANGE)
+ fatal(1, "add_1_const", "Integer overflow '%s'", r->name);
break;
case 'S':
r->color = add_const_str(interpreter, r);
There are a few more such conversions. But I don't know, how portable
that is.
$ parrot big.pasm
error:imcc:add_1_const: Integer overflow '4294967295'
leo
