Undefined Behavior in C and C++ (2024)

Post by lmkg » Tue, Aug 12, 2025, 11:52 AM UTC

JonChesterfield wrote: post #68

gpderetta wrote: post #62

Earlier quoted context omitted.

Pointer provenance already existed before, but the standards were contradictory and incomplete. This is an effort to more rigorously nail down the semantics. i.e., the UB already existed, but it was not explicit had to be inferred from the whole text and the boundaries were fuzzy. Remember that anything not explicitly defined by the standard, is implicitly undefined. Also remember, just because you can legally constr…

Pointer provenance was certainly not here in the 80s. That's a more modern creation seeking to extract better performance from some applications at a cost of making others broken/unimplementable. It's not something that exists in the hardware. It's also not a good idea, though trying to steer people away from it proved beyond my politics.

Post by pjmlp » Tue, Aug 12, 2025, 11:53 AM UTC

flohofwoe wrote: post #63

eru wrote: post #56

Earlier quoted context omitted.

> As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. Did they? What's your evidence? Are you including consoles? Btw, the alternatives in the 1990s were worse than they are now, so the bar to clear for eg C or C++ were lower.

I was there Gandalf... ;) Console SDKs offering C or C++ APIs doesn't really matter, because you can call C APIs from C++ just fine. So the language choice was a team and engine developer decision, not a platform owner decision (as it should be). From what I've seen, around the late mid-90's, C++ usage was still rare, right before 2000 it was already common and most middleware didn't even offer C APIs anymore. Of cou…

Post by pjmlp » Tue, Aug 12, 2025, 11:57 AM UTC

gpderetta wrote: post #71

pizlonator wrote: post #29

I don’t buy the “it’s because of optimization argument”. And I especially don’t buy that UB is there for register allocation. First of all, that argument only explains UB of OOB memory accesses at best. Second, you could define the meaning of OOB by just saying “pointers are integers” and then further state that nonescaping locals don’t get addresses. Many ways you could specify that, if you cared badly enough. My fa…

> nonescaping locals don’t get addresses inlining, interprocedural optimizations. For example, something as an trivial accessor member function would be hard to optimize.

Post by gpderetta » Tue, Aug 12, 2025, 12:07 PM UTC

ncruces wrote: post #83

gpderetta wrote: post #75

Earlier quoted context omitted.

I'm not a compiler writer, but I don't know how you would be able to implement any optimization while allowing arbitrary pointer forging and without whole-program analysis.

Why? What specific optimization do you have in mind that prevents me from doing an aligned 16/32/64-byte vector load that covers the address pointed to by a valid char*?

  void bar();
  int foo() {
    int * ptr = malloc(sizeof(int));
    *ptr = 10;
    bar();
    int result = *ptr;
    free(ptr);
    return result;
  }

  int foo() { 
      bar();
      return 10;
  }

Post by bluetomcat » Tue, Aug 12, 2025, 12:11 PM UTC

eru wrote: post #59

bluetomcat wrote: post #19

Earlier quoted context omitted.

Rust encourages a rather different "high-level" programming style that doesn't suit the domains where C excels. Pattern matching, traits, annotations, generics and functional idioms make the language verbose and semantically-complex. When you follow their best practices, the code ends up more complex than it really needs to be. C is a different kind of animal that encourages terseness and economy of expression. When…

Pattern matching should make the language less verbose, not more. (Similar for many of the other things you mentioned.) > When you know what you are doing with C pointers, the compiler just doesn't get in the way. Alas, it doesn't get in the way of you shooting your own foot off, too. Rust allows unsafe and other shenanigans, if you want that.