Strange Problem: integer value too large to represent.
Graham Mayer
set a 123456789123456
if {$a == "Hello"} {
puts "yes"
} else {
puts "no"
}
Error: integer value too large to represent
If I run the same script under the same version of Tcl on a Motorola
88k box running
UNIX_System_V R40V4.2, it works fine.
I suspect this might have something to do with a compile option, i.e. how Tcl was built on the HP box. If anyone can shed any light on this I would greatly appreciate it.
NOTE: We are also running TclX, BLT and OraTcl (just for completeness)
Graham Mayer
jeff_...@my-dejanews.com
Graham Mayer <grma...@ecid.cig.mot.com> wrote:
> I have encountered the above error running Tcl v 7.3 on an HP machine
> running HP-UX B.10.20 with commands of the form:
> set a 123456789123456
> if {$a == "Hello"} {
> Error: integer value too large to represent
> If I run the same script under the same version of Tcl on a Motorola 88k
> box running UNIX_System_V R40V4.2, it works fine.
Oh, Tcl7.3.. that's oooold. Anyway, the problem is that Tcl is trying
to figure out if $a is an integer first. You should really have that as:
if {[string compare $a "Hello"]==0} {
and you will avoid such problems. Tcl doesn't support bignums, and ints
are restricted to the number of bits the machine reps an int for
(normally 32). The above isn't a valid int on Solaris 2.5 either,
however, I don't get the problem where it tries to compare as an int
first...
jeff.hobbs @SPAM acm.org
jeffrey.hobbs @SPAM icn.siemens.de
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Frank J. Leitner
>I have encountered the above error running Tcl v 7.3 on an HP machine
> running HP-UX B.10.20 with commands of the form:
> set a 123456789123456
>
> if {$a == "Hello"} {
> } else {
> puts "no"
> }
TCL tries to use the numerical value of any string in expr evaluation
(the if condition is an expression). In 7.3 (up to 7.6, tested
on HP-UX 10.20), it throws an error if a string appears to be an
integer, but can't actually be converted to one.
TCL 8.0 works o.k.; but the better solution is to explicitly do
string comparision and not rely on the built-in magic of expr:
% set a 123456789123456
123456789123456
% if {[string match "Hello" $a]} {
puts "yes"
} else {
puts "no"
}
no
You could as well use "string compare". Using "string match" makes
the code IMHO more readable ( {[strimg match...]} vs.
{[string compare ...]==0}), but you need to put the known value
in the first position to avoid unwanted wildcard expansion.
--
Frank
Paul Duffin
While readability is important [string match] will be more expensive
than [string compare]. I have proposed in the past that Scriptics add a
[string equal] which will be both faster than [string compare] and more
readable.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Frank J. Leitner
>
> Frank J. Leitner wrote:
> >
> >
> > You could as well use "string compare". Using "string match" makes
> > the code IMHO more readable ( {[strimg match...]} vs.
> > {[string compare ...]==0}), but you need to put the known value
> > in the first position to avoid unwanted wildcard expansion.
> >
>
> While readability is important [string match] will be more expensive
> than [string compare]. I have proposed in the past that Scriptics add a
> [string equal] which will be both faster than [string compare] and more
> readable.
Seconed. Yes, this would be REALLY nice.
--
Frank