Re: [sv-ec] Re: [sv-bc] question about integer expression

I mostly agree with what Greg wrote, but with some minor differences.

I agree that there is no 32-bit context affecting the arithmetic of
those index expressions.  They are self-determined.  I agree that the
rewrites that Greg describes are not truly equivalent, but are just
descriptions of approximately what it means, for a human reader.

I also agree that it would be a mistake to rely on an index or range
value larger than can be represented in 32 bits.  I would be a little
more specific than Greg on this.  It should be fine to use an expression
wider than 32 bits, with arithmetic of that greater width.  However, you
should expect that the final result may be truncated to 32 bits before it
is used as an index or range value.  Intermediate values in the expression
may be wider than 32 bits, but the index itself will only be 32 bits.

I would go further than Greg and say that this is not just a practical
implementation issue.  The LRM contains indications that these indexes
are actually limited to 32 bits.  The size methods return ints.  Those
array locator methods that deal with indexes use ints for the indexes of
non-associative arrays.  In a foreach loop, a loop variable iterating 
through a non-associative array dimension is implicitly declared to be
of type int.  (Actually the text says that it is auto-cast to int if used
in an expression.  This would allow an implementation to use a larger
index for the iteration, as long as it treated it as an int when used in
an expression.  In practice, this is not much of a distinction.)  The
array query system functions $left, $right, $high, $low and $size all
return type integer.  There are probably indications in other places that
I didn't look.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.