|
|
Log in / Subscribe / Register

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 2, 2016 12:27 UTC (Wed) by excors (subscriber, #95769)
In reply to: Project for porting C to Rust gains Mozilla's backing (InfoWorld) by vasvir
Parent article: Project for porting C to Rust gains Mozilla's backing (InfoWorld)

http://huonw.github.io/blog/2016/04/myths-and-legends-abo... has some useful comments and links. It looks like Rust's basic behaviour is:

In debug mode, by default, signed and unsigned integer overflows panic (i.e. unwind the current thread's stack then terminate the thread). (Incidentally, unwinding the stack across FFI boundaries is apparently undefined behaviour, so if you ever call from C into Rust then the Rust code must either spawn a new thread to do all its work or else must be absolutely convinced it's not going to panic (which seems hard to guarantee if it's doing any arithmetic).)

In release mode, by default, overflows wrap as two's complement.

There could be compiler options to turn the checking on/off in different parts of the program.

It seems to be designed as a debugging feature, not a security feature. It's discussed as being equivalent to debug assertions, which are helpful during development but typically disabled in production for performance, so programs shouldn't rely on them to prevent exploits.

Integer types have some low-level explicit arithmetic methods: "wrapping_add" (always wraps), "saturating_add", "checked_add" (returns Some(n) or None on overflow). And for people who prefer operator overloading there's the "Wrapping" type, e.g. if "let x = Wrapping(0u32) - Wrapping(1u32)" then "x.0 == std::u32::MAX".

As far as I can tell from Corrode's source (admittedly I'm not very familiar with Literate Haskell), it uses the wrapping_add etc methods for unsigned arithmetic, and standard arithmetic operators for signed.


to post comments

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 2, 2016 19:36 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

> (Incidentally, unwinding the stack across FFI boundaries is apparently undefined behaviour, so if you ever call from C into Rust then the Rust code must either spawn a new thread to do all its work or else must be absolutely convinced it's not going to panic (which seems hard to guarantee if it's doing any arithmetic).)

There's another approach, which is preferred: use std::panic::catch_unwind in the Rust callee to catch any panics and convert them to some kind of error return.

> It seems to be designed as a debugging feature, not a security feature.

That's currently true. I find it very useful in debugging since it leads you straight to the root cause of the bug. Personally, though, I hope that one day, with improved compiler optimization or shifting performance/security tradeoffs the Rust team is able to enable overflow checking in release builds. Having it be enabled by default in debug builds now is an essential prerequisite for that, since it makes it much less likely that actual Rust programs depend on unchecked overflows.

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 3, 2016 11:25 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I'd rather have the overflow checking on by default, then if my program runs too slowly, profile it and turn off the checking just for the speed-critical part.

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 3, 2016 13:02 UTC (Thu) by kevincox (subscriber, #93938) [Link]

There are crates that do this (on nightly), but yes, that would be a cool option to have.

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 3, 2016 23:00 UTC (Thu) by ballombe (subscriber, #9523) [Link] (2 responses)

Keep in mind that gcc provides both -ftrapv and -fwrapv for C code. You do not need rust for that.

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 4, 2016 17:34 UTC (Fri) by thestinger (guest, #91827) [Link] (1 responses)

Neither of which works properly in GCC... although they do in Clang. In GCC, -ftrapv misses cases it should catch and -fwrapv isn't respected everywhere. Anyway, -ftrapv is only for signed overflow and is essentially obsolete. You really want the integer sanitizers in the trapping mode for that. In GCC, the implementation of those is also less buggy but still problematic, while it all works fine in Clang.

Project for porting C to Rust gains Mozilla's backing (InfoWorld)

Posted Nov 5, 2016 1:32 UTC (Sat) by lsl (subscriber, #86508) [Link]

> Anyway, -ftrapv is only for signed overflow and is essentially obsolete.

What else should it be? Unsigned wraparound is a standard language requirement und lots of code depends on it.

Do you have more info on the "-fwrapv isn't respected everywhere" part? Are these intentional or just bugs?


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds