Path: utzoo!attcan!uunet!wuarchive!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Bug in perl, pl36 (maybe?)
Message-ID: <10065@jpl-devvax.JPL.NASA.GOV>
Date: 22 Oct 90 19:35:20 GMT
References: <1990Oct22.181253.19779@lth.se>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 45

In article <1990Oct22.181253.19779@lth.se> jh@efd.lth.se (Joergen Haegg) writes:
: 
: 
: Hello.
: 
: I have found a bug in perl, well it seems to be anyway (could be the machine).

I think it's your machine.

: If I execute any perlprogram with the '-d' option I get a floating point
: exception.
: 
: This always occur after 'c'ontinuing from any line in perldb.

The line in perldb.pl that is triggering this is in the "c" case:

	$stack[$i++] &= ~1;

: The following perlscript is enough to repeat the problem:
: 
: $xx = 1;
: 
: Try this with 'perl -d filename'.
: When I continue, perl dumps.
: 
: It happens in eval(), line 383. For some reason str_gnum(st[2])
: returns 4294967294. The debugger tells me that this 'is not a number',
: and perl dumps when trying to assign 'value'.
: 
: Examining st[2] shows that str_gnum is correct, it's st[2] who has
: incorrect values. Now this may work on other machines, but not mine.
: I have not seen any other having the same problem.

4294967294 is a perfectly valid unsigned 32 bit long value, the value
of ~1 (or -2 in signed longs).  So the problem is after str_gnum().
The code in eval.c is:

	    value = (double)(U_L(value) & U_L(str_gnum(st[2])));

The value of U_L depends on how you've defined CASTNEGFLOAT, so you might
play with that.  You might also try putting the value of the str_gnum()
into a temp variable, in case the problem is a too-complicated expression
for your compiler.

Larry