[Info-vax] VMS Cobol - GnuCOBOL
Arne Vajhøj
arne at vajhoej.dk
Fri Mar 3 08:45:30 EST 2023
On 3/3/2023 7:42 AM, bill wrote:
> On 3/3/2023 6:59 AM, Johnny Billquist wrote:
>> On 2023-03-01 15:54, Dan Cross wrote:
>>> In article <ttnk0m$lg5$2 at news.misty.com>,
>>> Johnny Billquist <bqt at softjar.se> wrote:
>>>> Basically, if you multiply two numbers, and the result would be bigger
>>>> than the types involved, the result is undefined.
>>>
>>> Well...no. _unsigned_ integer overflow in C is well-defined (it
>>> has modular wrapping semantics; C11 sec 6.2.5 para 9).
>>> Similarly, overflow of signed atomics is well-defined (C11 sec
>>> 7.17.7.5 para 3), so this is not always true.
>>
>> I had actually missed that unsigned integers do have a defined
>> overflow behavior.
>> Yup. You were right. Sorry that I had to go and read the spec again.
> And it really doesn't matter whether the result is truncation,
> conversion to signed int, wrap around, throwing an exception or
> undefined. The answer is still going to be wrong and the calculation
> worthless. So, what's the point? Fix the damn code.
>
> Go ahead, blame the language again.
I do.
:-)
The choice that provide the safest code is to throw
an exception at integer overflow.
For the cases where modulus 2^n math make sense, then
either the developer would need to move data to a bigger
data type and do an explicit modulus or the language
could support:
modulus_math_only_use_if_you_know_what_you_are_doing {
// code
}
Arne
More information about the Info-vax
mailing list