From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Münstermann <mmuenstermann(at)betrusted(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 8.0.0beta1: make check fails on solaris8 |
Date: | 2004-08-11 14:12:43 |
Message-ID: | 4909.1092233563@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>> My best guess about it is that strtod() is actively broken on your
>> platform, and is recognizing the "infinity" input but returning an
>> incorrect endptr. I seem to recall that we've heard of such bugs
>> before. Can you check for any updates from Sun that might affect
>> strtod()?
Hmm, take a look at this:
http://tcl.apache.org/sources/tcl/compat/fixstrtod.c.html
So at least the Tcl guys are aware of an issue. It looks from this code
like they expect Solaris strtod to return an endptr one past the end of
the string. Which would explain the apparently random behavior, because
that would be uninitialized memory --- if it happened to contain a zero
then we'd not register a complaint, but otherwise we would.
So forget my previous proposed patch and try this one:
/* skip leading whitespace */
while (*num != '\0' && isspace((unsigned char) *num))
num++;
errno = 0;
val = strtod(num, &endptr);
+ if (endptr != num && endptr[-1] == 0)
+ endptr--;
/* did we not see anything that looks like a double? */
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2004-08-11 14:25:03 | Re: 8.0.0beta1: make check fails on solaris8 |
Previous Message | Fabien COELHO | 2004-08-11 14:05:59 | broken contrib/dbsize in cvs head? |