On Mon, Jul 12, 2004 at 09:29:23AM -0400, Dan Sugalski wrote: > On Mon, 12 Jul 2004, Nicholas Clark wrote: > > > On Mon, Jul 12, 2004 at 09:20:31AM -0400, Dan Sugalski wrote: > > > On Mon, 12 Jul 2004, Leopold Toetsch wrote: > > > > > > > 1) I've serious troubles with the precision of string_to_num. The test > > > > bewow fails, 1.e100 isn't really 10**100. > > > > 2) I've modified string_to_num to just use atof() which works. > > > > > > I so wish this were the case. Unfortunately it's not. atof's behaviour > > > isn't standardized across platforms--using it means that source will > > > behave differently depending on where it's compiled, which is bad. > > > > I'm pretty sure atof()'s behaviour can be standardised if one preprocesses > > to get rid of the C99 braindeath first (0x... being hex floating point > > constants) > > I'm not so sure. Perl 5 has its own string to number conversion because of > atof incompatibilites IIRC. (Which I may not) Granted, at this point all > those problems may well be gone, what with us requiring a C89 standard > compiler and all the platforms that have died, but I'm not so sure. > (Neither am I sure it'll work right in the face of all the potential float > sizes one can configure)
The real big problem was the first time we realised we'd encountered a C99 libc, and perl was converting "0x3" to 3, rather that 0 as the Camel says, because atof()'s documented C89 behaviour is broken by C99, and perl expected the the C89 behaviour. I don't remember any major reason to mistrust platform atof() apart from this, and this particular stupidity can be worked round by wrapping atof() in a vetting routine and chucking anything matching the hex constants /^0x/ back as 0.0 And I think that the principal reason perl didn't do this was because Hugo sent Jarkko a patch to implement atof() faster than I was able to write a vetting routine. I still consider perl's own atof() a bad move, because it's never going to be portable enough. Nicholas Clark
