Hacker News Reader

This is completely infeasible. A C compiler makes so many assumptions that UB does not occur that every program, even well functioning ones, would emit walls of warnings. Also, these warnings can't be silenced. Consider the integer division case: Should the warning be emitted every time division by zero is encountered at runtime? In that case, C would be much, much slower. Or should the compiler emit the warning whenever it can't prove at compile time that the divisor is not zero? In that case, you would get tonnes of situations where you can't fix the issue because you can't prove to the compiler it's not zero. Division by zero is a easy case. It gets much harder to emit warnings for aliasing assumptions, for example.

> A C compiler makes so many assumptions that UB does not occur that every program, even well functioning ones, would emit walls of warnings.

The problem here is that the C compiler ever assumes that UB doesn't happen. That is empirically very much not the case, therefore the compiler should never be allowed to assume a lack of UB unless it can somehow prove that to be true. I honestly don't really care how many optimizations that would break; correctness is king. Software that goes fast is only worthwhile if it works correctly.

> I honestly don't really care how many optimizations that would break; correctness is king.

It's approximately all optimizations. Good news: there's already a compiler option that does exactly what you want: -O0. It's even enabled by default (unless overridden by another -O switch)!

-O0 code also omits a lot of "Don't be very stupid about it" optimizations, it's not a realistic option for much production code.

A surprising number of those optimizations are only valid by "reasoning from undefined behavior".

Under the as-is rule, optimizations must not change program behavior. A C program could theoretically use out-of-bounds pointers to scan its own stack, observing whether a value occurs on the stack. Thus, the as-is rule prohibits storing local variables in registers!

But because out-of-bounds pointers are undefined behavior, the compiler can ignore the programs doing stack scanning, and so register allocation becomes possible under the as-is.

So boring old register allocation is one of those "assume that UB doesn't happen" optimizations! Of course, the compiler never actually reasons "this pointer arithmetic is out of bounds therefore I can put that variable over there into a register" -- the reasoning from undefined behavior doesn't happen at compile-time, it already happened when the "register allocation" optimization was designed. But that's the case for most "assume that UB doesn't happen" optimizations! (this is also why it's so difficult for compilers to warn about undefined behavior -- they optimize based on it without ever detecting it!)

If you want to eliminate "reasoning from undefined behavior", you'd also need to replace the "as-is" rule with something else -- an explicit list of allowed optimizations in the language standard?

Indeed. No UB is something no mainstream C/C++ compiler does (and maybe ever did). Benchmarking the performance impact will require basically rewriting GCC or LLVM, an insurmountable task, because the assumptions are so ingrained.

Though it might be possible to have more "sensible" UB. For example, assuming daemonic non-determinism for allocation address it is possible to turn stack storage into registers, without the need for an aliasing model. Benchmarking it has the same difficulty.

The problem is really surprising UB. I don't think that an experienced C programmer blames the compiler if some pointer offset trick to manipulate variables on the stack stops working. Compilers used to be "less smart", so they didn't get too clever about UB neither. Now they do and it surprises developers. That is a real problem.

A challenge is that it doesn't seem like people agree on what "surprising" UB is. I don't think it would be totally unreasonable to have a compiler mode that specifically assumes that all arithmetic operations are total functions, which covers many of the scenarios that show up in blog posts. But there is somebody in this comment thread who is upset that you can't read from an uninitialized heap address to obtain unpredictable data.

My personal observation is also that it only surprises developers when they read blog posts about it and that this actually comes up quite rarely in practice.

s/as-is/as-if/

You are otherwise correct of course.

> The problem here is that the C compiler ever assumes that UB doesn't happen.

Imagine you have a tail-recursive function and you'd like to convert it to iteration. This is only semantic preserving if there is no UB!

Or worse, if you can never assume that UB doesn't occur then you need all code to be compiled in a way that defends against data races. You can't change the allocation order on the stack, since there might be some write past the end of a buffer and now suddenly stack allocation order changes the semantics of the program. Nightmare.

Imagine this program:

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

Can we use constant propagation to replace "x" with 1 in the instructions? No. After all, a could smash the stack and write over x. You need a new read of that memory location every time you plan on using x.

The compiler should emit a warning at compilation time, when it decided to replace the conditional with single branch, throwing away the condition itself and the second branch.

If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler. If that expectation was wrong, compiler should inform me about that.

> If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler.

It's very common to write code in templates or inline functions expecting the compiler to remove it if it's not relevant on the calling site. That's part of what makes "zero cost abstractions" have zero cost at runtime.

For instance, I have a SIMD routine with extra code to process the tail (leftover elements smaller than the native vector size). When the compiler can prove that the size of the input will always be a multiple of the vector size (which is very common for my use cases), it will completely remove that tail handling code.

They you'll see that warning and mark your extra code to remove that warning, because you're aware that it's subject to potential elimination.

I think the point is that your code will light up as a Christmas tree, since basically anything could be eliminated in specific contexts. For example, the loop that handles vector-width parts of the array can also be eliminated (as in the condition/branching). If the compiler can prove that there will only be a small, fixed number of iterations, it will just unroll the loop.

> If I wrote some code, I expect it to be present in the binary.

That's oversimplified. If after inlining and constant folding an if-condition turns out to be always true or false I would definitely expect that the compiler removes the dead branch.

This type of optimization is the base for the fabled "zero-cost-abstraction" (which isn't only a C++ thing, C code depends on it just as much), and removing those optimization would seriously tank peformance in any non-trivial codebase.

How about if the compiler translates a pointer deference into a read of that memory address? That is potential undefined behaviour that has been "optimised" into something simpler than a safe operation (tracking all memory allocations and checking if the pointer is correctly pointing into one of them). So every pointer deference would also generate a warning (except perhaps where the compiler can prove from local information that it's safe).

It is definitely a hopeless path.

Turning off all arithmetic simplification is a wild choice.

Suppose you have the following program:

unsigned f(unsigned x) { return 2*x; }

Can this be optimized to instead perform a bit shift? That's faster than multiplying. But you wrote a multiplication operator. Should the compiler be responsible for keeping it?

I'd say the alternative is the rust approach. of debug mode always doing checked div and checked add ops. this prevents a large class of issues which you can find in debug mode. In release mode those UB checks are dropped. You of course can specify the type of add you want i.e saturating or wrapping etc. But yeah it makes things slower but the alterative is the code potentially doesn't work. Linux is funny in this regard which i think is why Linus allows rust and not c++ because potentially not working is a big deal in a kernel. C++ doesn't address this issue and of course C does not C++'s potential UB space is so much bigger because of alliasing issues and object patterns exposing more chances for UB.

Regardless you are right there is a cost is it worth paying hard to say

> of debug mode always doing checked div and checked add ops. this prevents a large class of issues which you can find in debug mode. In release mode those UB checks are dropped

Checked divs are present in release mode too. Omitting them would be UB.

Other checks (e.g. for additions) are omitted in release mode, but they were not preventing UB in the first place because they guard a wrapping addition, not an unchecked one (the kind that's UB in C).

First we need to reduce the UB zoo because the types of UB in the C standard go all over the place (from "no newline at end of file" to "oops, this specific UB combined with this specific code compiled on this specific version of this specific compiler with these specific compile options leaks execution into the next function").

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

Do you think it'll become like, say, HTML5?

Accepting tag soup led to differences in rendering per browser. Trying to go harder on correctness, XHTML, was just too strict for people to write themselves. WHATWG came to the conclusion that they should standardise how to correct badly-written HTML, rather than say "do what you want" for anything that doesn't parse correctly.

I don't know what to expect tbh, and I'm also even fine with the current behaviour :)

AFAIK the C committee is on the right track though. Start with collecting and classifying all mentions of UB in the standard (IIRC it's somewhere around 200 items), then decide what to do with each of those. A lot of the UB items are completely silly ancient artifacts which can easily be clarified (like the "no newline at the end of a source file").

Then there's probably quite a few items that can become implementation defined behaviour instead.

And only then decide what should happen to the remaining UB items that are actually important for optimization, maybe require a new 'checked mode' which turns those cases into runtime errors.

Also I think the "nasal demons" problem needs to tackled somehow (e.g. the thing that a compiler is allowed to do anything in the presence of UB) - obviously this is the trickiest part, and in reality there's hardly any C program which doesn't contain UB.

Most UBs are runtime conditions, and inserting runtime checks would defeat the point of optimizing for them not possibly happening.

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)

It's not about inserting checks. It's about removing code that I wrote from the binary. That should not happen silently.

You can get that behaviour (mostly) already today by simply not enabling optimizations.

The resulting performance difference is basically the price to pay for such a 'strict' compiler which translates the input source code straight into machine code instructions without attempting to simplify the output code via inlining, constant folding and dead code removal.

-O0 program is useless and should be written with any other language. The whole point of C is to use compiler with optimizations. I'm not against optimizations. I'm against optimizations that perform things unexpected by the programmer. Dead code removal is unexpected by the programmer, because programmer does not write dead code.

Well you can't have your cake and eat it too ;)

> Dead code removal is unexpected by the programmer, because programmer does not write dead code.

Of course it is expected, because the optimizations leading to dead code are fundamental for the performance you get out of a release-mode binary (and that's also true for languages with less UB like Rust btw).

When you have a function:

    static int add(int a, int b) {
        return a + b;
    }

And you call that function with const parameters:

    int c = add(2, 3);

Then you want that entire function call to be removed and "folded" into its result 5, and when this was the only place the function was called, you'd also want the actual function to be removed from the binary (because what's the point of lugging code around in the binary that's guaranteed to never be executed).

The "code" is `a + b`. The rest is just decorations.

Here's example from article:

    static int f(int a, int b)
    {
     x = b ? 42 : 43;
 return a/b;
    }

Compiler can inline `f` but if it removes conditional branch, that's where issue is. I wrote this branch because I expected `b == 0` to be a valid value. Compiler deduced that it can't be a valid value and decided to remove `43`. That's understandable. But let me know, so I'd rewrite my code myself instead. Because I have assumptions and compiler have assumptions and these assumptions do not match. It means that there's a bug.

So you expect the compiler to tell you every time it inlines a function with a null check in a function which already had a null check on the same value?

Because as far as it’s concerned that is the same thing.

Both clang-tidy and sonar will flag this since it’s broken on its own, but when you’ve fixed it you want the compiler to warn you every time this is inlined in a function where b is known non-zero and the check is redundant?

As flo told you, if you want a non-optimizing compiler use a non-optimizing compiler.

I suggest you write such a compiler then or at least curate your own set of approved optimizations (compilers allow much more fine grained control than -O levels) if you refuse to take anyone's word that undefined behavior is required for good optimization.

Strictly speaking it’s not, a better type system can provide intent as basis for optimisation e.g. rust’s unique references being definitionally non-aliasing does translate to optimisation opportunities (so much so that it found a ton of bugs in llvm’s noalias handling since it hit those in so many more ways than C or C++ codebases would).

> Dead code removal is unexpected by the programmer, because programmer does not write dead code.

Dead code elimination is like the single most profitable optimization in the compiler, especially in conjunction with inlining and constant propagation that makes several branches become trivially dead. And its removal is very much expected by programmers, because (for example) bounds checking tends to work by generating bounds checks for every possible array access and relying on the compiler to be able to prove most of those bounds checks redundant.

No, my suspicion is you're actually only against certain kinds of dead code removal, but the kinds you're against are so inconsistent that it's impossible to implement a decision program except by including a routine to read the programmer's mind.

> I'm not against optimizations. I'm against optimizations that perform things unexpected by the programmer.

DWIM is not a spec.

Surprisingly safer languages can perform such optimisations without UB.

well, yes, because those languages can statically or dynamically guarantee that behaviour that would be UB in C or C++ doesn't happen.

Usually it means GC, bound checking and no pointer forging.

I am counting languages since 1958 starting with JOVIAL, many of which did not had GC.

Plenty of literature on the matter, some retro computing fun, or using some of the survivors in modern platforms, for example Ada.

I agree but also disagree. You would be upset if it removed the condition from something like this:

    void clear_buf(char *buf, size_t len) {
        char *end = &buf[len];
        if (end < buf) return; /* in case len is so long the pointer wraps the memory space */
        while (buf < end) *buf++ = 0;
    }

(which it can do, by virtue of saying that constructing a pointer beyond end of buf is itself undefined behaviour, therefore it can expect that end is never less than buf. the more appropriate way to write this is "while (--len > 0) *buf++ = 0" and let the compiler invisibly change that to end=buf+len if it thinks that'll work in all situations and be more efficient than counting down len while moving along buf)

...but you wouldn't be upset if it changed this:

    for (int i = 0; i < 1000000; i++) {
        if (i < 5) foo(i);
        /*else something_else(i);*/
    }

to effectively this:

    for (int i = 0; i < 5; i++) {
        foo(i);
    }

or even:

   foo(0); foo(1); foo(2); foo(3); foo(4);

Imagine this program:

  int main() {
    int x = 0;
    return g(x);
  }

  int g(int x) {
    if (x == 0) return 1;
    return bar();
  }

  int bar() {
     ...
  }

Can this program be simplified to just

  int main() {
    return 1;
  }

Simple inlining, constant propagation, and dead code elimination gets you there.

> But I want to have loud warnings! Like WARNING: this conditional operator has been collapsed to one branch because earlier division by zero is UB.

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

""code can be result of macro expansion"

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

you are indeed wrong.

Relevant:

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

If your compiler concludes "you will encounter UB" then it will stop and yell at you. What you are encountering is something different.

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

A compiler class computes the possible ranges that x and y can take at the return statement. Another pass does arithmetic simplification and simplifies the final instruction to "return 0." Should the compiler warn you here? No, obviously.

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.