in reply to bug in Perl compilation?

Similar comments have come up before. While I would consider the case the OP showed a bug -- more likely in the underlying C compiler than in the source code for Perl (see below) -- it is also fairly well known that floating point is, most emphatically, not isomorphic with real numbers. See, for some more information:

What every computer scientist should know about floating-point arithme +tic Source ACM Computing Surveys (CSUR) archive Volume 23 , Issue 1 (March 1991) table of contents Pages: 5 - 48 Year of Publication: 1991 ISSN:0360-0300 Author David Goldberg Xerox Palo Alto Research Center, Palo Alto, CA

The reason I would consider this behavior to be a bug is that it only occurs on one system. I'm blaming the C-compiler because I would expect the numerical processing code is among the least system-dependent parts of the Perl source.

Replies are listed 'Best First'.
Re^2: bug in Perl compilation?
by bkgallo (Initiate) on Dec 21, 2005 at 20:29 UTC
    I also suspect it's a bug in the C compiler. So this begs the question of how to correct this situation. But first a clarifying question: does this behavior occur because the C compiler (which has the suspected bug in it) is accessed at runtime or was the bug "hardcoded" into Perl during Perl's compilation by this C compiler?

    If the behavior occurs only because the C compiler is accessed during runtime then it may be only a case of getting the latest C runtime compiler patch to correct this behavior.

    If the behavior occurs because the C compiler had a bug during Perl's compilation then either Perl will have to be recompiled (with an updated C compiler, of course) or a new Perl installation of previously compiled-for-Linux code will have to be installed.

      I also suspect it's a bug in the C compiler.

      No, by default, perl uses its own atof() implementation to convert strings to numbers instead of the one from libc. It is explained inside the perl.h file from the perl source.