Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 21:06:48 +0300
Organization: Tidorum Ltd
Lines: 66
Message-ID: <lkradoFp9aeU1@mid.individual.net>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vbcob9$dvp4$1@dont-email.me> <vbd6ia$e0ld$2@dont-email.me>
 <UxpCO.174965$Hld5.7714@fx15.iad> <vc41rl$1fhjd$1@dont-email.me>
 <2024Sep14.152652@mips.complang.tuwien.ac.at>
 <d93c1dc0455692767c89ea9f7bd47ed1@www.novabbs.org>
 <vc4o0l$1kuqf$1@dont-email.me> <vc6vno$285g2$1@dont-email.me>
 <vc8qor$2od9v$1@dont-email.me> <vc99fi$2re3k$2@dont-email.me>
 <20240916160402.0000087f@yahoo.com> <vc9e72$2smso$1@dont-email.me>
 <tkYFO.77534$kxD8.10093@fx11.iad> <20240916185857.000011ef@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net BGVHmP5j5aokU4cTqyLRTwaYBewrj0s8vjQ8vdZVRNjDrK8+54
Cancel-Lock: sha1:ppxgXvq5eA0MUS+tSyMJ7TGh3BM= sha256:ElgggO+TWS1ohjRJZWEpm53tf8JrpDCb1KF4QnxTE+I=
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <20240916185857.000011ef@yahoo.com>
Bytes: 4281

On 2024-09-16 18:58, Michael S wrote:
> On Mon, 16 Sep 2024 11:39:55 -0400
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
> 
>> David Brown wrote:
>>> On 16/09/2024 15:04, Michael S wrote:
>>>    
>>>> With one exception that usize overflow panics under debug
>>>> build.
>>>>   
>>>
>>> I'm quite happy with unsigned types that are not allowed to
>>> overflow, as long as there is some other way to get efficient
>>> wrapping on the rare occasions when you need it.
>>>
>>> But I am completely against the idea that you have different
>>> defined semantics for different builds.  Run-time errors in a
>>> debug/test build and undefined behaviour in release mode is fine -
>>> defining the behaviour of overflow in release mode (other than
>>> possibly to the same run-time checking) is wrong.
>>
>> In the compilers that do checking which I have worked with
>> there was always a distinction between checked builds and debug
>> builds. In my C code I have Assert() and AssertDbg(). Assert stay in
>> the production code, AssertDbg are only in the debug builds.
>>
>> Debug builds disable optimizations and spill all variable updates
>> to memory to make life easier for the debugger.
>> One usually compiles debug builds with no-optimize and all checks
>> enabled.
>>
>> But debug, optimize, and checking are separate controls.
>>
>> In the compilers for checking languages I've worked with,
>> checking and optimization are compatible.
>> For example, if the compiler uses an AddFaultOverflow x = x + 1
>> instruction to increment 'x' then it knows no overflow is possible
>> and then can make all the other optimizations that C assumes are true.
>>
>> And on those compilers checks can be controlled with quite fine
>> resolution. Checks can be enabled/disabled based on kind of check,
>> eg scalar overflow, array bounds,
>> for a compilation unit, a routine, a section of code,
>> a particular data type, a particular object.
>>
>> This was all standard on DEC Ada85 so if Rust compilers do not
>> do this now they may in the near future.
>>
> 
> If ability to control compilers checks was standard on DEC Ada then it
> made DEC Ada none-standard.


No, it means that DEC Ada could be used as a standard-conforming Ada 
compiler or as a non-conforming compiler, to a user-chosen extent.

The recommended approach today (for applications where it matters) is to 
use static analysis of the Ada code (e.g. SPARK or other tools) to prove 
that run-time errors cannot happen, which then makes it possible to omit 
the corresponding run-time checks while staying compliant.

I don't know if Rust code can be analysed as easily and completely as 
Ada code can. But Ada compilers usually allow fine-grained control over 
which checks are applied where, not just a single choice between "debug" 
and "production" builds.