Re: [TCLCORE] Re: TIP 132 and NaN

[Donald G P. <dg...@ni...>]

> During the early discussions of TIP 132, the issue was raised
> that checking in [expr] does not suffice, because extensions
> (including Tk) could also get unexpected NaN's if somehow
> the string "NaN" or one of its variants were to reach
> Tcl_GetDoubleFromObj (which prior to 8.5, rejected NaN's
> entirely).  

The code of the Tcl_GetDoubleFromObj() routines does not
indicate that.  A "pure NaN" has clearly been able to pass
through Tcl unmolested.

When conversion to/from string rep is considered, then whether
or not NaN values could pass through Tcl dependend on
what the sprintf() and strtod() routines did with them.

If I'm wrong in that analysis, please correct me.

It's true that one couldn't portably rely on passing NaNs through
Tcl, but it's certainly possible that this worked on at least
some systems.  This incompatibility will strike there.  For those
users, if we don't rethink this, we need a good explanation and
an alternative to offer.

> An extension that is prepared to handle NaNs gracefully
> can check this case with a few lines of code - the way,
> for instance, that the 'FormatNumber' function in tclBinary.c
> does.

If the alternative is to be along these lines, I think it
would be better to make TclGetNumberFromObj() public and
offer that.  (That's probably a good idea anyway.)

For the sake of getting 8.5a4 done, I'm going to omit this
issue from the Tcl_GetDoubleFromObj documentation revisions.

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