Tcl Source Code

These changes were committed today
without reference to anything in the
Tracker.

Recording the patch here so it may be
reviewed, and its purpose may be
explained.

Logged In: YES 
user_id=80530


Yes, and the patch is a fine
workaround until TIP 249 fixes
all these matters correctly.
thanks.

Logged In: YES 
user_id=90858

This is just a little bug that slipped in with TIP 72.
Nobody is going to
expect that the literal -2147483648 is going to parse
differently than
the string "-2147483648" in an expr.

Logged In: YES 
user_id=80530


thanks for the followup.

so this patch is undoing part of TIP 72?
Do I understand that right?

Or is it correcting a (buggy) behavior
change that happened separate from
TIP 72?  When did the undesirable
behavior show up?

Anyhow, I think TIP 249 will take care
of such matters in 8.5.  Open question
whether anything needs to happen
for 8.4.12 and later on this point.

Logged In: YES 
user_id=90858

Hello gents

The bug fix was just for parsing of a literal LONG_MIN
value. These
two expr commands would both return 1 in earlier versions of
Tcl.

set min_long -2147483648

expr {($min_long - 1) == 0x7FFFFFFF}

expr {(-2147483648 - 1) == 0x7FFFFFFF}

The current version was parsing the number "2147483648"
as a 64 bit long long and then it would keep it as a wide type
thinking that it was out of the long range.

Re the other tests. These are just tests for expr functionality
that were not already covered someplace else. I am writing
a Tcl -> Java compiler for Jacl and these test cases were
developed as part of the process. Since they all pass already,
it seemed safe to check them in.

Logged In: YES 
user_id=80530


Issue appears to be a parsing ambiguity
when the literal LONG_MIN value appears
in an expression.

expr {-0x80000000}

The string "-0x80000000" is recognized
by Tcl as a non-wide integer:

  % string is integer -0x80000000
  1

However, the **expression** "-0x80000000"
gets parsed into unary operator "-" followed
by literal value "0x80000000" and the result
becomes a wide integer.

Same issue, just less obvious, with the
expression -2147483648 .

Did I get that right?

With true EIAS numbers (where we're headed?)
this will no longer matter (right?), but since 
currently wide vs. non-wide changes computations,
I can see that this is an issue in need of resolution.

kennykb, any comments from the numerics reform
leader?

Logged In: YES 
user_id=80530


Although the patch adds ~30 new
tests, the only one that I see with
different outcome before and
after the changes to tclExecute.c
is test expr-33.2 .

This appears to be a detail of
the boundary between recognition
of literal integer value as wide vs. non-wide,
which is notoriously tricky, and not
historically consistent; i.e. something that
needs some review.

I don't really know what the intent
of all the other additional tests is.

File Added - 140229: mo.patch