BUG #2111: Error parsing 'infinity' under some versions of glibc - Mailing list pgsql-bugs

From Neil Parker
Subject BUG #2111: Error parsing 'infinity' under some versions of glibc
Date
Msg-id 20051213202221.76EDEF0B32@svr2.postgresql.org
Whole thread Raw
Responses Re: BUG #2111: Error parsing 'infinity' under some versions of glibc
List pgsql-bugs
The following bug has been logged online:

Bug reference:      2111
Logged by:          Neil Parker
Email address:      nparker@microniche.com
PostgreSQL version: 8.1.1
Operating system:   Linux (Slackware 8.0, with kernel 2.2.19, glibc 2.2.3)
Description:        Error parsing 'infinity' under some versions of glibc
Details:

PostgreSQL fails to parse the string 'infinity' as a floating point number
under some versions of glibc on Linux.

To reproduce:
* Unpack PostgreSQL 8.1.1 on a Linux system with glibc-2.2.3.
* configure
* make
* make check
* watch as it complains "float4 .. FAILED" and "float8 .. FAILED".

Looking in regressions.diffs, the problems begin with
     SELECT 'infinity'::float4;
This is supposed to return
   float4
 ----------
  Infinity
 (1 row)
Instead it produces
 ERROR:  invalid input syntax for type real: "infinity"
All the other tests of 'Infinity' fail the same way, and likewise with
float8.


This problem appears to be glibc's fault, not PostgreSQL's.  In version
2.2.3 of glibc, strtod()
parses "inf" as infinity, but (contrary to the documentation) it stops there
and doesn't go on to check whether the input string is the full word
"infinity".

The following C code shows the problem:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
        char *num = "Infinity";
        char *endptr;
        double d;

        d = strtod(num, &endptr);
        printf("result is %f, len is %d\n", d, endptr-num);
        exit(0);
}

If this is compiled and run under glibc 2.2.3, the output is "result is inf,
len is 3".

The problem is fixed in later versions of glibc...the output under glibc
2.3.2 is "result is inf, len is 8".

Below is a patch that fixes the problem on the affected system.  It's at
best a stopgap, and I can't guarantee that it won't break floating-point
parsing on other systems, but with this in place PostgreSQL passes all its
regression tests on the affected system.

*** postgresql-8.1.1/src/backend/utils/adt/float.c.orig Fri Oct 14 19:49:28
2005
--- postgresql-8.1.1/src/backend/utils/adt/float.c      Tue Dec 13 11:31:03
2005
***************
*** 282,288 ****
        val = strtod(num, &endptr);

        /* did we not see anything that looks like a double? */
!       if (endptr == num || errno != 0)
        {
                /*
                 * C99 requires that strtod() accept NaN and [-]Infinity,
but not all
--- 282,288 ----
        val = strtod(num, &endptr);

        /* did we not see anything that looks like a double? */
!       if (is_infinite(val) || endptr == num || errno != 0)
        {
                /*
                 * C99 requires that strtod() accept NaN and [-]Infinity,
but not all
***************
*** 449,455 ****
        val = strtod(num, &endptr);

        /* did we not see anything that looks like a double? */
!       if (endptr == num || errno != 0)
        {
                /*
                 * C99 requires that strtod() accept NaN and [-]Infinity,
but not all
--- 449,455 ----
        val = strtod(num, &endptr);

        /* did we not see anything that looks like a double? */
!       if (is_infinite(val) || endptr == num || errno != 0)
        {
                /*
                 * C99 requires that strtod() accept NaN and [-]Infinity,
but not all

pgsql-bugs by date:

Previous
From: "Alexei"
Date:
Subject: BUG #2110: initdb set wrong default encoding
Next
From: Stefanos Kozanis
Date:
Subject: Re: BUG #2084: Add WIN1253 to CLIENT_ENCODING encodings