Re:An RFC that adds support for Rust to the Linux kernel
by nwmcsween on Saturday April 17, 2021 @04:26AM
(#26842588)
If there is one implementation as the definition then by default all behaviour is defined by the implementation, and hence parent is correct.
Re:An RFC that adds support for Rust to the Linux kernel
by wmanley on Tuesday April 20, 2021 @09:54AM
(#26874687)
No. If we accept your argument then this would be correct:
> In absence of a standard effectively every language construct is 'implementation defined behaviour'.
But the parent said:
> In absence of a standard effectively every language construct is 'undefined behavior'.
Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.
Re:An RFC that adds support for Rust to the Linux kernel
by nwmcsween on Tuesday April 20, 2021 @05:44PM
(#26882191)
I didn't state 'implementation defined behavior' which encompasses more than the Rust implementation. The Rust implementation defines the behavior, for example signed int overflow.
Re:An RFC that adds support for Rust to the Linux kernel
by roca on Thursday April 22, 2021 @05:30AM
(#26900636)
The "Rust Book" says signed integer overflow to be two's complement in release builds and panic in debug builds:
https://doc.rust-lang.org/book/ch03-02-data-types.html
That's clear enough for programmers to rely on. It is nonsense to argue that this is equivalent to C's "the compiler may do anything it wants" just because the "Rust Book" is not called the "Rust Standard" or not "formal" enough.
For more see: https://blog.regehr.org/archives/213 and https://raphlinus.github.io/programming/rust/2018/08/17/unde... .