IMCC uses atof() because it doesn't use (need?) any of the encoding stuff. (See add_const_num() in imcc/pbc.c). Packing the cstring up in a STRING then calling string_to_num() *fixes* the problem, but it doesn't address the issue Larry brought up. The interpreter makes heavy use of the encoding sensitive STRING type, the compiler does not.
I'm not very familiar with the garbage collector, would the call to string_make() be a memory leak? Or will it be collected?
diff -r1.68 pbc.c 593c593,594 < int k; --- > int k, l; > STRING *str; 594a596 > str = const_string(interpreter, buf); 596d597 < 600c601,602 < (FLOATVAL)atof(buf); --- > string_to_num(str); >
Larry Wall wrote:
On Wed, Mar 17, 2004 at 04:13:40PM -0500, S. Livingston wrote: : Oops, use this one instead... "re"-fixes the exponent support...
This still doesn't explain why the compiler would be using a different routine to turn the string 1.2 into a number than the run time does. This is not code that should be duplicated. Or am I misunderstanding the problem?
Larry
