Liste des Groupes | Revenir à c arch |
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.
Les messages affichés proviennent d'usenet.