Reducing undefined behavior in the C language

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

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.

    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.

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...

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).

Might be wrong but the big issue with warning about UB probably isn't C it's C++ and it's templates. Modern C is mostly what you see is all there is. Where with C++ lord knows really.

C is often a bit slower than C++. Which also means trading a little speed to eliminate UB isn't a big hit. Where doing that inside a template expansion can slow things down a lot.

My preferred solution is people stop using C++.

Suppose you have the following program.

    int f(int x, int y) {
      if (x < 0 || y < 0) return -1;
      if (x > 100 || y > 100) return -1;
      return x + y > 200;
    }

What you want is for this to only warning you if some conclusion about the program that led to a simplified conditional operation came from an assumption about UB. But compiler passes can't really track the "whys" of each conclusion it makes. It spreads so broadly so quickly.

What Every C Programmer Should Know About Undefined Behavior https://blog.llvm.org/2011/05/what-every-c-programmer-should...

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."

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.

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.

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

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)

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!

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.

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.

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).

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

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.

> 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.

    int main() {
      int x = 1;
      a(x);
      b(x);
      return x;
    }

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);
    }

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.

Almost always, overflow is a logic error no matter what behavior the compiler defines for it so you need to make sure it doesn't happen anyway.

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.

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.

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.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

These days, it's mostly taken as an invitation by very powerful compilers to sometimes do heroic optimizations (that we like) -- and sometimes screw us over in really obscure ways (which we don't like). We would really like to keep their ability to perform heroic optimizations and that's why there's so much pushback against eliminating undefined behaviour.