There are many things that are present in assembly but lacking in C. For example, how do you detect integer overflow in C without resorting to compiler extensions?
A minimal porting effort for the best of all worlds.
You might not get the best optimization possible if you have to leave it up to the C compiler with inline assember... But that mix worked well for C and C++.
And rust can still optimize things like deciding which integer optimizations need the overflow check, and only add it where static analysis failed.
How often will idiomatic rust code need overflow checks?
Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course.
One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).
No, you're talking about all signed addition.
> How often will idiomatic rust code need overflow checks?
You'd be surprised. Go look at the implementations of containers in the standard library.
> Also, if the UB operations are defined by target assembler (instead of in C++) then you may not even need extra overflow checks, depending on the assembler semantics. This would only be needed in the places where static analysis failed, of course.
I don't know what this means exactly. If you're saying you should implement a static analysis to try to eliminate unneeded overflow checks, then this is a huge burden.
> One could also use the native compiler options, if available, to avoid the issue alltogether (like -fwrapv).
If you're dependent on GCC/clang extensions to C, then you're not compiling to C. You're compiling to a front end to GIMPLE/LLVM. At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.
No, I'm talking about the ones that won't overflow. Some can be statically shown to not need a runtime check.
> If you're dependent on GCC/clang extensions to C, then you're not compiling to C.
I'm not saying that. I'm saying require either the target compiler (which the user is in control of) to provide a flag to give signed overflow the proper semantics (which would be useful if the user happens to be using clang or gcc), or fall back to requiring some asm for the target system which provides the needed semantics.
This would all be up to someone to configure for the target machine. Not a big deal once per architecture.
> At that point there's no benefit over just compiling to GIMPLE or LLVM in the first place.
Well if GIMPLE or LLVM was available for all of the targets that C compilers are, then I'd agree.
But they aren't. So I don't.
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
could be implemented in plain C if you're careful. It's not like the other extensions like __builtin_constant_p or asm that'd leave you stuck with GNU C.
And besides, GNU C is good enough for lots of people!