Re: Optimization techniques and error detection

On Wed, 1 May 2019 09:20:23 +0200, David Brown
<david.brown@hesbynett.no> wrote:


>On 01/05/2019 03:24, Gene Wirchenko wrote:
>> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>> [snip]
>>
>>> If you are writing your code in a "C with the extra feature of having
>>> defined behaviour on signed integer overflow", and only compile it with
>>> suitable compilers (or compiler flags), then that's okay. But don't
>>> call it correct C code and blame compilers for your own mistakes or
>>> unwarranted assumptions.
>>
>> I would like to see it as part of the language. I *know* that I
>> want to have an error be thrown at run-time if an error can be
>> detected. (It is not an unwarranted assumption.) It is not as if
>> detecting signed integer overflow is a difficult thing on, for
>> example, System/370, which also dates from 1970.
>
>Detecting signed overflow at run-time can be a significant cost. It


          Not detecting it can have a significant cost, too. Incorrect
results can cost.


> ...
>No, throwing an error on overflows is not hard - but it /is/ costly. It
>can be a marvellous tool during testing and debugging, and may be worth
>leaving active in some programs, but it has a price.


          I do not deny it has a price, but I do not care about the price.
I want the correctness. Others have different priorities: fine, but I
want my priorities dealt with, too.


Sincerely,


Gene Wirchenko

Return to the comp.compilers page.
Search the comp.compilers archives again.