Re:Ferrous Systems ends partnership with AdaCore
by blub on Saturday September 30, 2023 @07:02AM
(#37714300)
> Just the fact that Rust has well defined semantics for overflows would save so much time and money
This is a compile-time option in GCC and clang (fwrapv).
Re:Ferrous Systems ends partnership with AdaCore
by rcxdude on Saturday September 30, 2023 @09:05AM
(#37715045)
The question is whether the certified version of them defines the behaviour of the flag sufficiently to be accepted as a means og achieving that outcome. It can be very difficult to do anything not endorsed by the standard, even if it's widely implemented.
Re:Ferrous Systems ends partnership with AdaCore
by Xylakant on Saturday September 30, 2023 @10:26AM
(#37715745)
> Alas, using Rust was not a viable option when the project(s) I work with were started.
We hope things will change. One of the nice things about Rust is that it can integrate into C in both directions - using C libraries is possible, as well as building components for C codebases. Quite a few of the people we talk to explore (re)writing critical components in rust.
I can tell from $WORK experience that writing safety certified C or C++ code is very expensive and not fun.
For my line of work (systems programming for automotive industry), using Rust would be a massive improvement over C or C++. The amount of undefined behavior pitfalls and footguns is a big hindrance to productivity.
Perhaps the most labour intensive part is dealing with integer overflows in a way that keeps static analysis tooling happy. Just the fact that Rust has well defined semantics for overflows would save so much time and money.
Alas, using Rust was not a viable option when the project(s) I work with were started.