[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