BUG #2111: Error parsing 'infinity' under some versions of glibc

From: "Neil Parker" <nparker(at)microniche(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #2111: Error parsing 'infinity' under some versions of glibc
Date: 2005-12-13 20:22:21
Message-ID: 20051213202221.76EDEF0B32@svr2.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


The following bug has been logged online:

Bug reference: 2111
Logged by: Neil Parker
Email address: nparker(at)microniche(dot)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

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jim Dew 2005-12-13 23:46:53 BUG #2112: query kills db thread
Previous Message Tom Lane 2005-12-13 18:26:08 Re: PQexecParams performance