[Chabsff]

On the flip side, languages like C,C++ and Rust have the major benefit of having next to no runtime component to it, allowing trace-driven fuzz testing to achieve a much higher level of confidence in its test coverage. For a tool like sudo, this can matter a lot.

[nullc]

I think this is really important and it's a big part of what makes it unrealistic to write critical software in Python or Java: It's too slow to get extremely deep testing, even with fancy tricks like snapshotting the execution state to avoid startup costs.

But, that said, Rust code compiled in debug mode which required to get integer overflow detection is slow enough that it severely degrades the ability to use fuzz testing on many codebases, FWIW. I believe the reason is that debug mode always disables numerous optimizations that are required to make rust performant at all because of all the boilerplate emitted by earlier stages of compilation.

AFAIK there isn't a way to get the equivalent of GCC's "-fsanitize=undefined" (or -ftrapv) for checking for unexpected overflows at a performance cost similar to "-fsanitize=undefined" performance cost on C code.

It's still a much better situation than python or java, I think-- but an area that could use improvement which won't be improved if rust is above criticism.

[steveklabnik]

You can pretty trivially turn on overflow checks yet compile with all of the other release options as normal. It's one line in cargo.toml or one flag to rustc.

[nullc]

What is the one line? (I shall benchmark!)

[steveklabnik]

iirc it's `-C overflow-checks=y` to rustc or

  [profile.release]
  overflow-checks = false

in cargo.toml.

I would probably use the flags with RUSTFLAGS to make sure that it goes to all dependencies and not just the crate you're building, if what you're building has dependencies.

[nullc]

Thanks!

[steveklabnik]

… I just realized that second should have been true not false. Lol. Hope I didn’t lead you astray.