Date: Mon, 06 Mar 2000 20:19:10 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: iang@systemics.com Cc: current@FreeBSD.ORG, perl5-porters@perl.org Subject: Re: [ID 20000306.004] unpack(NaN) big baddaboom Message-ID: <9874.952370350@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 06 Mar 2000 15:10:20 -0400." <200003061910.PAA75240@systemics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200003061910.PAA75240@systemics.com>, Ian Grigg writes:
>> Depending on your religion the bug is either in perl itself which
>> should be more careful about NaN and Inf values, or in the perl
>> script you supply which does something which is patently bogus,
>> but nothing which should provoke a FP trap according to IEEE.
>
>I don't know much about religion, but this feels like
>a Perl bug to me. I feed a highlevel command a number
>I read off the wire, and it blows up. As I have no
>control over the wire (it's a network) I cannot *not*
>handle the number.
I would agree with that.
>> I would argue that as long as your perl script doesn't use the NaN
>> in an operation which IEEE documents as giving a trap ( compare of
>> two floats for ordered magnitude for instance) then your perl
>> interpreter shouldn't either.
>
>Well, in that sense, this is my workaround:
>
> my $data = $is->read(4);
> #
> # Damn, FreeBSD throws Floating Point Exception on NaN!
> #
> my $long = unpack("N", $data);
> if ($long == 2143289344)
> {
> return "NaN";
> }
That is not enough, NaN has multiple binary representations.
isnan(3) is your friend.
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9874.952370350>