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 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: References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <2024Sep14.152652@mips.complang.tuwien.ac.at> <20240916160402.0000087f@yahoo.com> <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 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.