#2742 expr {"Nan"}

final: 8.3.5
closed-out-of-date
5
2004-05-30
2004-05-25
Anonymous
No

The expr command, when given the literal string "Nan"
(quotes included), tries to convert Nan to a number and
yields the error:

domain error: argument not in valid range

Clearly, what's inside quotes is not expr's business,
it shouldn't open that box !

Also notice that this strange behavior is insensitive
to whitespace, but it to other characters:

expr {"Nan xyz"}

works correctly.

Discussion

  • Logged In: YES
    user_id=496139

    This was me (sorry I hadn't logged in).
    Maybe one useful detail:

    The same problem arises if the Nan results from an evaluation:

    proc foobar {} {return Nan}
    expr {[foobar]}

    So we can reinterpret this as: "expr systematically tries to
    convert its final result to a number". This is at odds with
    Tcl's lazy conversion spirit, and definitely a bug !

    -Alex

     
  • Don Porter
    Don Porter
    2004-05-25

    Logged In: YES
    user_id=80530

    be sure to reconcile any
    changes here with Bug 218000

     
  • miguel sofer
    miguel sofer
    2004-05-25

    • assigned_to: msofer --> dkf
     
  • Logged In: YES
    user_id=79902

    Tcl's NaN handling is an utter mess. But [expr] is (IIRC)
    defined to be aggressive about trying to convert its result
    into numeric form.

     
  • Logged In: NO

    sorry, i couldn't logged in

    i tried this command but not foumd any error in it as it
    printing "Nan"

     
  • Logged In: YES
    user_id=496139

    Look at the header: I tried this on 8.3.5.
    So please give the [info patchlevel] where you no longer
    have the bug.
    I'd like to know the critical version where this was fixed.
    Any idea, frome those who know expr's changelog by heart ?

    -Alex

     
  • Logged In: YES
    user_id=79902

    8.4 had a bit of work in this area, but it turns out that
    many platform libc's aren't good here. :^(

     
  • Logged In: YES
    user_id=79902

    The expr.n manual page states that:
    "If an operand does not have one of the integer formats
    given above, then it is treated as a floating-point number
    if that is possible."

    Thus, [expr] is correct to regard "Nan" as a float, and is
    at least not vastly wrong in regarding that as a domain
    error (because that's what generates NaN values normally.)
    8.4 should be a bit better at handling this.

     
    • status: open --> closed-out-of-date