Opened 11 years ago

Closed 11 years ago

#3593 closed bug (fixed)

strtod doesn't support "INF" input

Reported by: Adek336 Owned by: axeld
Priority: normal Milestone: R1
Component: System/ Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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

int main()
	char * endptr;
	double d = strtod("inf", &endptr);
	fprintf(stderr, "%f '%s'\n", d, endptr);
	return 0;

The expected form of the subject sequence is an optional plus or minus sign, then one of the following:


* One of INF or INFINITY, ignoring case
* One of NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part, where:[...]

Change History (3)

comment:2 by Adek336, 11 years ago

Additionaly, strtod failed with this testcase

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

int main()
   double d = strtod("+8E153", NULL);
   printf("%.10e\n", d);
   return 0;

Linux result: 8.0000000000e+153
Haiku result: 7.9999999873e+153
The testcase is inspired by the results of running "python" for the floating point test.
Both python 2.6 on Haiku-gcc4 and python 2.7 on Haiku-gcc2 we print the following message -

    self.assertEqual(v, eval(repr(v)))
AssertionError: 7.9999999872500254e+153 != 7.9999999745000492e+153

The test which errors out in python is equivalent to

x = "+8E153"
v = eval(x)
assert v == eval(repr(v))

So it looks like #3308 's issue is caused by problems with strtod(). Our implementation comes from FreeBSD. The following is the last revision of their stdtod.c file; in later revisions, FreeBSD uses gdtoa ( link to NetBSD gdtoa as I couldn't find an online viewable FreeBSD link ):

However, importing rev 112256 of FreeBSD's strtod.c into the Haiku tree and doing a full rebuild doesn't help.

comment:3 by zooey, 11 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev31919, by using the strod()-implementation from glibc, which already lived in our repo.

Note: See TracTickets for help on using tickets.