[TCLCORE] C9X, strtod(), hex floating literals

[Don P. <dg...@ca...>]

I upgraded the OS on my Alpha this week from Red Hat Linux 5.1 to
Red Hat Linux 6.2 and encountered a platform dependency of the
Tcl Core we should figure out how to resolve.

When the Tcl Core needs to determine whether a string can be
converted to a floating point number, it calls on the C library's
function strtod() -- declared in <stdlib.h> -- to make that
determination and to perform the conversion.

The ISO C9X standard for C and the C library extended the set
of string formats for representing floating point numbers to
include "hexadecimal floating-point constants".  For example,
the string "0x1.b5p4" is now to be recognized by strtod() as
a string convertible to a floating point value.  For more
details on the C9X standard, you can start at

	http://web.onetelnet.ch/~twolf/tw/c/c9x_changes.html

Some C libraries have started to conform to the new strtod() spec,
including the GNU C library, version 2.1.  If your platform has
such a library, you will see different Tcl behavior than on other
platforms that don't have such a library.  Try the following script
to see which behavior you have:

	set hex [list 0 1 2 3 4 5 6 7 8 9 a b c d e f]
	foreach d0 $hex {
	    foreach d1 $hex {
		foreach f $hex {
		    lappend l 0x$d1$d0.${f}p0
		}
	    }
	}
	set sl [lsort -real -inc $l]	;# Magic of strtod() converts strings
					;# to doubles according to a C9X
					;# hexadecimal-floating-constant
					;# representation, and sorts them.
	foreach e $sl {
	    puts "$e = [expr {$e}]"	;# Fun with dual-porting!
	}

Pre-C9X libraries should give an error about "expected floating-point
number but got 0x00.0p0".  C9X compliant libraries should print a
table showing how some hex floating point literals get mapped to
a decimal floating point representation.

Problems:
    1. Cross-platform consistency of Tcl is undermined.

    2. [expr] does not recognize the new format.

	% expr 0x0.00p0
	syntax error in expression "0x0.00p0"

	I had to use [lsort] above to convert the hex formatted
	strings into floating point values, because it calls on
	strtod() -- via Tcl_GetDoubleFromObj() -- directly.

	OTOH, [expr] first tries to interpret the string as an
	integer -- because TclLooksLikeInt() returns true --
	and then is confused because it doesn't recognize the
	'.' or the 'p' as valid operators.

	This means different commands in the built-in command set
	of Tcl have different opinions about what is a valid
	floating point number.

    3. Implementation of C9X strtod() may be buggy or inconsistent.

	I'm not convinced the results of the script above on my
	GNU C library 2.1-based system are consistent with the
	C9X spec.  The spec is just vague enough that I can't say
	for sure -- grrrr.  Let's just say that the GNU C library
	interpretation of the spec isn't the one I would make.  It
	will be interesting to see any results from the above script
	on other platforms with libraries claiming C9X compliance
	and see whether they match.
		
    4. Do we want to expose another C format for numbers at script level?

	Given the confusion over octal numbers, does it really make
	sense to add script-level support for another format mostly
	suitable for precise bit-by-bit specification of floating point
	values?  That sort of thing is necessary in a system programming
	language like C, but is it really a benefit for Tcl?

Recommendation:

Tcl already includes the file compat/strtod.c with an implementation
of strtod() to use when Tcl's configure script determines the native
strtod() is buggy.  I recommend that Tcl's configure script also test
for the presence of a C9X strtod(), and replace it with the compat/strtod.c
version as well.

Any problems with that plan that I'm not thinking of?  Other comments
from the community?

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.