A pair of Rust kernel modules
A pair of Rust kernel modules
Posted Sep 15, 2022 20:19 UTC (Thu) by khim (subscriber, #9252)In reply to: A pair of Rust kernel modules by Wol
Parent article: A pair of Rust kernel modules
But the thing is: this is what was supposed to happen with C and C++, too! Except for safe subset, but otherwise it was planned like that.
I mean… the Rationale for International Standard— Programming Languages— C says: Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.
This is your Tower of Weakenings right there!
Note that before C89 was punished it actually worked that way: there was no standard but different implementations permitted different things and even if some were not so easy to implement (e.g. one-element-past-the-end-of-array means it becomes impossible to have simple 64KiB arrays on MS-DOS) they were added to standard where it made sense.
I wonder how that stance turned into “if standard says something is undefined behavior then we have the carte blanche to destroy the program” and then “if standard doesn't say something is undefined behavior yet then we have the permission to destroy your program anyway”.
I don't think there was some evil mastermind behind all these developments, but the end result sure is complete lack of trust.
Periodic Linus outbursts and public complaints is not how you plan development of language which is used by millions!
Posted Sep 15, 2022 21:35 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Portability I would guess. Once more than one compiler could target a given platform (or one compiler could target more than one platform), "my compiler/platform is better than yours" creeps in and you start down the path of "what kinds of optimizations can we squeeze out here?" come up.
Today? Code that is written to work on multiple platforms from the same source. Here, the compiler saying "well, if it were $obscure_arch, this is different behavior, so we'll show it to you on your machine via UB-based optimizations (but not make any noise about it either)".
On one hand, a UB-less C would be "safer", but its portability would tank because "it worked on my x86_64" means diddly squat when you compile it for aarch64.
Posted Sep 15, 2022 22:33 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
You've missed "implementation defined" and "hardware defined".
If something is "hardware defined" then yes, just because it works on x86_64, you can't expect the SAME code to work on aarch64, but firstly the programmer will KNOW that they need to check behaviour, and secondly they can put the ifdefs and whatever in there, and know that that IS DEFINED behaviour.
The *only* grounds for UB should be because "we can't define it because we can't get the logic to add up". There's no need for the C/C++ standard to define everything itself - it can defer the definition to something else - but all behaviour should be defined *somewhere*, if a definition is possible.
Take for example the size of a byte. In *PRACTICE* it's always 8-bit nowadays. I wouldn't be surprised if it's actually already implementation or hardware defined, but that's a perfect example of something that makes perfect sense as hardware-defined. In places, bytes are 6 bits, and if the programmer doesn't account for it it will cause a major problem if they're targetting an old platform. But the standard CAN, and SHOULD, address it.
Cheers,
A pair of Rust kernel modules
A pair of Rust kernel modules
Wol