Re: Kind of NOT integer constant

Jan Vorbrüggen wrote:
....
>> i = 2147483647
>> j = 2147483645
>> li = i+j
>> print *, li, (i+j)/2
>>
>> Is the processor prohibited from printing
>>
>> 4294967292 2147483646
>>
>> even if the answer for the second value *is* permtted?
>
> If the answer for the second value were permitted, I would _require_,
> for consistency, the first value you show. However, I think in this
> example the second value is not permitted: the expression i+j is
> evaluated with a result the same kind as i and j, which for this being
> a 32-bit integer will lead to overflow. [...]

There is no concept of overflow in the standard document.
An implementation is not required to detect, report, or
"wrap" values on overflow. It *IS* permitted that it carry
extra precision for the intermediate calculations of an
integer expression. Otherwise, I would say, for consistency,
that the corresponding floating point example would *have*
to overflow:

dble_var = huge(0.0) + huge(0.0)

And we all know that the standard does *not* require that
to overflow.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.