On 29 December 2000, I wrote:
> ... For example, how is the following code handled?
> class MAIN
> creation make
> feature make is
> print(( "2147483646").to_integer.out + "%N")
> print(( "2147483647").to_integer.out + "%N")
> print(( "2147483648").to_integer.out + "%N")
> print(( "9999999999").to_integer.out + "%N")
> print(("-2147483646").to_integer.out + "%N")
> print(("-2147483647").to_integer.out + "%N")
> print(("-2147483648").to_integer.out + "%N")
> print(("-9999999999").to_integer.out + "%N")
Thanks to Johan and Alexander for running this test and reporting the
results for SE and VE. In addition to the result that I reported earlier
for HACT 3.1, I ran the test for ISE 4.5 and got the same result as for
Here are the combined results. The first column is the value of the
STRING being converted. The second column is the result using ISE and
HACT, and the third column is the result using VE and SE:
STRING ISE/HACT VE/SE
"2147483646" 2147483646 2147483646
"2147483647" 2147483647 2147483647
"2147483648" 2147483647 -2147483648
"9999999999" 2147483647 1410065407
"-2147483646" -2147483646 -2147483646
"-2147483647" -2147483647 -2147483647
"-2147483648" -2147483648 -2147483648
"-9999999999" -2147483648 -1410065407
As you can see, all compilers give the same result for values in the
range minimum_integer to maximum_integer inclusive.
We could capture the common behaviour by adding a precondition to
'to_integer', constraining the input string to represent a value between
2147483647 and -2147483648 inclusive. This could be expressed
informally, or perhaps formally by exploiting the lexical sort order of
the STRING using the design suggested by Arno Wagner and others. Does
anyone want to have a go at formulating this precondition, remembering
that we must allow for the optional leading zeros and leading sign
allowed by the BNF?
A formal or informal precondition along those lines would correctly
capture the common behaviour of the current compilers, but ideally we
should strive for a precondition that would abstract out the dependency
on a 32-bit INTEGER.
I can't see how to achieve that here (because 'maximum_integer' and
'minimum_integer' are not available to a precondition of class STRING).
[Although ETL2 says class ANY inherits from PLATFORM, this was
explicitly changed in ELKS95, which made PLATFORM a standalone class.]
If a future language revision adds ISE's "creation expression" extension
to the Eiffel language, then we would be able to use the values of...
...within the expression of a precondition assertion.
Perhaps someone else can find another way to remove the dependency on a
32-bit INTEGER. Failing that, we will at least have an informal but
rigorous specification that captures the common behaviour of all current
implementations. That's still be a pretty big step forward for
Roger Browne - roger@...
- Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428