The Linux Foundation's "security mobilization plan"

The output of the compile-time code might be more code, not just data. E.g. it might compile a regex into an efficient matching function (like https://github.com/hanickadot/compile-time-regular-expres...). In general it seems impractical to implement that as two separate programs, since the first program would need to be a preprocessor with a sophisticated code parser/generator - and at that point it's no longer a workaround, it's a full implementation of metaprogramming for your language (but harder because you're choosing to serialise the processed code to text and parse it again).

Maybe regexes aren't the best example, I think they're self-contained enough that you could do most of them with Rust's procedural macros (which usually operate over ASTs). But that C++ library also lets you split the pattern from the regex compilation, like "constexpr auto pattern = ctll::fixed_string{"..."}; ...; auto matcher = ctre::match<pattern>;", which I think is impossible with Rust macros because the AST can't tell you that the two 'pattern' identifiers are the same variable - most name resolution doesn't happen until after macro expansion. Other use cases for metaprogramming (maybe like Eigen - https://eigen.tuxfamily.org/dox/TopicInsideEigenExample.html) may depend more heavily on resolving names/types/etc from the surrounding code, so they couldn't work at all with Rust macros. And they can't work with generics or const fn which are far too limited in other ways.

At the end of the day, UB is a *BUG* waiting to bite people, and when statements like "if I detect an access to *freed_ptr it's UB so I can format the hard drive if I like" are literally true, it shows up the C spec as the farce it really is.

C was (and is still seen as) a glorified assembler. It should not be deleting safety checks because "this isn't supposed to happen" when the programmer has determined it can - and does - happen.

I'm quite happy with the C spec offloading responsibility - 6-bit bytes and all that. I'm quite happy with the spec saying "this shouldn't be possible - here be dragons". The problem is when compiler writers spot UB in the spec whether by accident or looking for it, and then CHANGE the behaviour of the compiler.

If the C spec is changed to say "there is no such thing as UB, it is now as a minimum Implementation-Defined, even if the IDB is simply "Don't do it, it's not valid C"", then it will stop C being a quicksand of nasty surprises every time the compiler is upgraded.

Otherwise we will soon end up (and quite possibly a lot quicker than people think possible) where the core of the Linux kernel is written in Rust, and the only C left will be legacy drivers.

Cheers,
Wol

int *const p = (int*)malloc(sizeof(int));
free(p);
int *const q = (int*)malloc(sizeof(int));
*q = 5;
*p = 7; /* use after free */
if (*q != 5) launch_missiles();

Say the second malloc() happens to return the same address as the first, which is perfectly valid since that memory was freed. The memory _does_ belong to the program, but now it's part of a different object. The consequences of writing to it cannot be defined by the hardware or the compiler as they depend on the rest of the program, implementation details of the C library, and the particular circumstances present at runtime (e.g. other threads allocating or freeing memory).

I'll grant you "potentially disastrous consequences"—but that's just another way of saying "undefined behavior".

> Likewise "the result of accessing *null_ptr either behaves as defined by the hardware/OS, or must be defined by the compiler".

This is a slightly more reasonable request, since it can be accomplished portably by inserting checks for null pointers at every point where a potentially-null pointer might be dereferenced. Of course this comes at a considerable cost in performance in situations where there is no reliable hardware trap for dereferencing a null pointer, such as most systems without MMUs. If you're doing away with the strict aliasing rules as well then you'll need even more checks since previously valid pointers could be changed to null pointers as a side effect of seemingly unrelated memory accesses.

You don't seem to realise what "undefined behaviour" means. Undefined behaviour is simply any behaviour that has no definition within the standard. The set of such behaviours is, of course, almost infinite: almost every C implementation has at least some things that go beyond the C standard. Any call to a library function not defined within the standard is undefined behaviour, so as soon as you have separate compilation you are doing a lot of stuff that (from the perspective of a compiler running over some other translation unit) is not defined (which is why it has to assume that e.g. arbitrary things can happen to memory across function calls). It is quite possible that such functions are not written in C at all.

POSIX is similarly undefined: the C standard does not define it (though POSIX is more or less a superset of it and includes the entire C standard by reference, this is certainly not true of *everything* that impacts systems that run C code but is actually rather rare).

In places, the standard does specifically call out that some behaviours are not defined in addition to simply not defining them, but even if you changed all those places to explicitly nail down a definition, there would still be countless places *with no corresponding text in the standard* where some element of the behaviour of a system running C code was not defined in the standard (as you'd expect when there was no text there). A good thing too, or C wouldn't be much use anywhere.