Hi all..

I have a hextranslation and calculator cgi (Don Libes cgi.tcl based)
that will not respond to error catching if the int value is too
large to represent:

Output(cgi-debug -on):
cstr=34000000000+6&s=3&hexin=0x23&type=3

An internal error was detected in the service software. The
diagnostics are being emailed to the service system administrator
(root).
Heck, since you're debugging, I'll show you the errors right here:

integer value too large to represent
    while executing
"expr $sum [extract "s" $t] $el"
    ("foreach" body line 8)

The return is called catch {return [procname]}
This is not a problem catch can handle?
Do I have to implement a string length type error check?

How would you all handle this?

This sounds like it could be a known (and since fixed) bug; however,
only the tcl8.4 alphas were suceptible to it. See the report at
https://sourceforge.net/tracker/index.php?func=detail&aid=542142&grou...

If you provide some more details, maybe we can help. In the meantime, a
possible workaround is to use an intermediate variable

    if {[catch procname result]} {
        ... handle ...
    }
    return $result

miguel

using tcl 8.3.3 on the webserver, so I don't think that the bugged catch
evaluation in a return was the problem.
I did as you suggested and wrapped an intermediate step in the procedure,
that works to a degree.

More details:
 1.Read in user supplied numeric list,initialize sum to zero.  
 2.catch {foreach n userlist ,set sum [expr {$sum < 1 ? $n : [expr $sum $op $n]}]}
 3.end foreach
 4. catch {return $sum}

However large numbers still cause the incorrect sum to be displayed or
pseudo undefined behavior, depending on the operator.
I guess the only real solution is just to test $n??
set n [expr {[string length $n > $MAX ? [string range $n 0 [expr $MAX - 1]] : $n}]

                        .
                        .
                        .

marsd, I agree there's a real issue here.  For all
that Tcl's used in network management (NM), it's a
shame we don't have a crisper answer.

I'll review the conventional alternatives:
1.  Do all calculations with doubles.
2.  Use mpexpr or another explicit "bignum"
    extension <URL: http://wiki.tcl.tk/528 >.
3.  Cobble together a special-purpose extended
    long.  I put your approach above in this
    category.
4.  Ask Donal what the prospects are for 64-
    bit-arithmetic-the-way-NMers-understand-it.
--

Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html