struct User {
        char name[100];
        bool is_admin;
    };

Both also require recompilation of everything, which might be possible for CHERI but not for Fil-C - which is why, for example, there cannot be Fil-C support for Windows or macOS.

If so, then said compiler should still have support for (u)int_8/16/32/64_t. Said compiler already needs to have that support with (unsigned) _BitInt(8/16/32/64)—and, yes, one can also have 36-bit ints on x86_64 in C23 with _BitInt(36) if one must—and allowing stuff like int32_t and uint32_t will allow said (imaginary) 2200 system to cleanly compile a lot of pre-C23 open source code out there. Yes, uint32_t will look a little ugly at the assembly level, just as _BitInt(36) will look a little ugly on, say, a Xeon processor, but the code will compile and run the same.

Of course, these days they can buy tokens so an agent can do any relevant porting, but still.

Yes, but that's perhaps an argument for 'implementation defined behaviour', not in favour of 'undefined behaviour'.

Also AFAIK the point where UB causes 'runtime disruption' is way after the C frontend in the optimizer passes, e.g. much too late for issuing compilation warnings even if the UB situation could be detected (because as far as I understand the problem, the breakage happens mainly because of unexpected 'spooky actions at a distance' between different optimizer passes, e.g. a specific optimizer pass doesn't even notice that it broke the code).

You can get runtime errors for a lot of serious UB problems via UBSAN though of course (at the cost of some performance).

For the static ones there are often warnings you can set, but you’ll have to go through the list. Or possibly external checkers (e.g. clang-tidy has one for infinite loops but not sure it’s 1:1 with the optimiser on complex cases)

Memory error checking in C and C++: Comparing Sanitizers and Valgrind (quite comprehensive) - https://developers.redhat.com/blog/2021/05/05/memory-error-c...

It is not, and that's the issue. If it was just "high level assembly" there would be no UB, and no need to have UB. Instead you have UB (although arguably not all of it is really needed) because you need optimizations, which in turn you need because otherwise C would be too slow for that "operating system" job.

> code which is called thousands of times per second

Scripting languages can easily have loops running thousand of times per second and even more. You're off by some order of magnitudes here if you want to describe operations that happen in operating systems.

The problem with C is that modern compilers do a lot of transformations between your source code and the final machine code, so the actual behavior could be very far afield from what you would expect.

> And I'm not even sure if Rust solves this case as far as UB is concerned.

If your entire program is inside unsafe, then Rust is actually worse than C as far as UB is concerned. On the other hand, no one writes Rust like that, and Rust restricts all UB to unsafe blocks.

That's already a fundamentally wrong assumption :) With today's compilers, C is a high level language like all the others. The optimizations happening to C code are not fundamentally different than for any other compiled high level language.

> We should discourage the usage of C in application programming and prod application developers towards memory safe languages like Rust or Go.

No that's rubbish, just as it would be rubbish trying to 'discourage' people from writing programs in assembly code or any other programming language.

Ultimately, guaranteeing "safety" is the job of the sandbox your untrusted code is running in (e.g. the browser, operating system or VM).

The only difference between Rust and any "unsafe" language should be that one fails already at compilation time and the other at runtime (because the sandbox killed your rogue process).

E.g. if an operating system is exploitable because it allows untrusted programs to leak out of the sandbox, then that problem must be fixed in the operating system.

Fortran has historcally led this realm (see the Numerical Recipes book).

Julia is a newer option, and I understand that both are commonly used in Python objects.

https://numerical.recipes/

"Read the older 2nd ed. book in Fortran online for free."

Compile time is not the main issue with static analysis. It's that C doesn't provide enough information and not the right information to make it efficient and effective.

If you add this info you unavoidably will end up with something looking like Rust.

(Whose long compile times are not caused by its static analysis parts BTW)

While I don’t condone writing new code in C, there are major conceptions about its relationship to performance and C++.

Edit: To be fair for the current topic it's more of an "Inverted Design-by-Contract" issue. The compiler infers the contract via UB instead of exposing it to the developer.

when you divide a/b the contract b != 0 is formed on the function signature, but never made visible. Then someone inevitably violates the invisible contract and all hell breaks loose.

    // What the developer thinks the signature is
    int f(int a, int b);

    // What the compiler secretly changed the signature to
    int f(int a, int b) 
        __attribute__((requires(b != 0))); // The invisible contract!

In the general case it can not, that is why they were made UBs in the first place.

And that is generally not how compilers see UB, they don’t look for UBs lying around, they assume UBs can’t happen and use that for constraints, which they then propagate.

For instance

    *i = 1
    if (id) { … }

And this occurs and is extremely desirable every time e.g. a function is inlined in an other one which already checked for null.

In other words: if you write `a[i]` in C, the compiler could either add index checks if its knows the size of `a` with `abort()` calls; or it can just compile it to single access instruction. The latter is faster. The former might be useful for debug build, I guess, but otherwise it's too slow to be acceptable for C usage.

You dereference a pointer? That changes the contract of the function so that you must never pass in a non-nullable pointer.

Divide by b? You are not allowed to pass in a zero as b parameter to the function.

But you don't get to see that. Nobody tells you.

Does Rust define what I get when I dereference NULL in unsafe code? I doubt it, since it would require a NULL check before every pointer dereference.

The only insane thing about UB is that compiler writers took what everyone understand meant "the compiler emits what it emits and you get what you get" and turned it into "since it's undefined it means it can never happen so we can delete your null check".

if (x > 0) {…}. But what if you entered the body when x <= 0?

if (false) {…}. But what if you execute the body?

These are “impossible”. What happens when the impossible occurs is “undefined”.

When the older standards said signed integer overflow for addition is undefined what they are actually saying is that the real definition of + is:

    int +(int x, int y) { 
      assert(in_range(actual_math_add(x, y), signed_int_min, signed_int_max));
      return machine_add(x, y);
    }

But, in the interest of performance, “release mode” (which in this case is just any compilation) elides asserts since as a programmer you should not write code that asserts in much the same way that you should not write assert(false) in a normal code path that is supposed to run. Assertions are intended for “impossible” code paths and usually get compiled out in “release mode” though maybe your code is buggy and can actually hit them and then your program goes off the rails because it had a bug.

Put another way, if you did write assert(false) in a regular code path, would you find it unreasonable for the compiler to just delete the code after it? That is what undefined behavior is for.

Rust's unsafe mode, for instance, has undefined behavior. A whole list of them, in fact.

> Surely the compiler can just check if each access is valid.

Well, sometimes it can, but sometimes it doesn't know how long the array is. What if the array is passed as a pointer?

> Maybe each array could be annotated with its size at runtime, and accesses could be checked at runtime too.

That works, but it adds runtime cost that may legitimately be too much for some applications, for example, a Gameboy game (set aside that many Gameboy games were written in assembly).

> Fine, so we'll make the programmer promise to ensure array accesses are always valid. Maybe they'll make a mistake sometimes, but what's the worst that could happen? Throwing your hands in the air and saying the compiler is allowed to do anything, that's just stupid.

Well, maybe it's stupid, but this is one thing that could happen if you accidentally write past the end of an array: https://www.youtube.com/watch?v=Vjm8P8utT5g. I'm sure neither the programmers nor compiler writers intended that.

Ultimately, the compiler can't guarantee any behavior if its assumptions are violated. The example may seem contrived, but it demonstrates that, given the right circumstances, the results of the logical contradiction are unbounded. This is a direct consequence of the "Principle of explosion": https://en.wikipedia.org/wiki/Principle_of_explosion. On second thought, maybe the runtime costs of array bounds checking are an acceptable trade-off after all.

There wasn't room for safe programming practices, and direct manipulation of the hardware was a design requirement.

It assumes that you know what you are doing.

There are also ports to the Zilog Z80, an architecture with similar limitations (UZI, FUZIX).

That's not true. There is a difference between normative text and informative text. Informative text is not authoritative, and you were citing an appendix that is labeled as informative.

> I am hoping the up and coming C2y spec has very clearly defined behavior when using unintialized memory (ideally where it will work but the bytes can have any values).

It won't. Uninitialized memory can't have "very clearly defined behavior" without breaking essentially every single implementation, and WG14 is very loth to break existing implementations.

    int* p = malloc(sizeof(int));
    int v = *p;
    if (!(v < 0 || v == 0 || v > 0)) {
        exit(1);
    }

However if you are willing to restrict what programs you allow, you can make guarantees possible.

Silly example: if you compile valid (safe) Rust programs to C, you know that the resulting code will not invalidate Rust's borrowing rules by construction; and in principle you could try to establish this guarantee just from the C code alone, never having seen the Rust original.

However, you still wouldn't be able to have an algorithm that tells you for any arbitrary C code whether it has these problems or not.

C23 already requires 2's-complement representation for signed integer types, but signed overflow still has undefined behavior. I think that mandating 2's-complement wraparound would be a mistake.

Some instances of undefined behavior can be detected at compile time. For example, if I write

    int too_big = INT_MAX + 1;

If you evaluate n + 1 and it's possible for n to be equal to INT_MAX before the addition what do you want the result to be? Would quietly yielding INT_MIN really be useful?

Ideally, if I (accidentally) evaluate INT_MAX + 1, I'd like to be told that I've made a mistake. C doesn't have a good mechanism for doing so.

gcc has a non-standard option "-fsanitize=signed-integer-overflow" that can be used to catch signed overflow at runtime. If signed overflow yielded a well defined result, that option would be non-conforming.

However if you wan, you can already get that via a flag in pretty much any C compiler you care about.