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: