Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 18:58:57 +0300
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <20240916185857.000011ef@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 16 Sep 2024 17:58:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7b4ecf2c0b8427f1b1d344bec1b1bd8b";
	logging-data="2968006"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/56vLqmkbJKhnLu1nYtJok2zePjJgah9k="
Cancel-Lock: sha1:DkZGmh8qSFODmG2UFJpT7XvCWQo=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3600

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.