Liste des Groupes | Revenir à c arch |
On Mon, 16 Sep 2024 16:09:38 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 16/09/2024 15:04, Michael S wrote:On Mon, 16 Sep 2024 14:48:50 +0200
Okay.Rust has it in form of builtin functions wrapping_*()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.
>
Yes. If it is not behaviour you can rely on (and if it is a run-time error in debug mode, you certainly can't rely on it!) then the compiler should be able to optimise ignoring the possibility of it happening, when checks are not enabled.But I am completely against the idea that you have different definedOn the one hand, Rust manual says that integer overflow in release mode
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.
>
>
wraps. On the other hand, it says that "Relying on integer overflow’s
wrapping behavior is considered an error."
It does not sound particularly consistent and rather close to worst of
both worlds.
However on more important issue of out-of-bound array access Rust isI think it is difficult to determine the relative importance of out-of-bounds array access and contradictory documentation about basic arithmetic!
consistent,
Les messages affichés proviennent d'usenet.