Undefined behavior can result in time travel (2014) | Hacker News Reader

Undefined behavior can result in time travel (2014)

devblogs.microsoft.com

80 pointspcr91030323 comments

I used to work on lower level stuff a place with a large C++ codebase designed by a bunch of C guys. We had tight memory requirements, so a custom operator new (not nothrow) was supplied; but exceptions were also disabled, so the supplier of operator new couldn't throw in their implementation.

So that's how it was, and the code base was littered with lots of little checks on what new expressions were returning, things like:

  int *p = new int[1024];
  if (!p) return SOME_ERROR;
  doSomething(*p);

Of course, the C++ standard says that operator new will never return null (it's supposed to throw if it fails). So the compiler sees this code and says "hey, that if (!p) check isn't necessary.." and so none of those little checks gets emitted. Sure enough, it happens that the operator new returns null now and then because everyone is on a tight memory budget, but instead of catching it and returning an error, the code just goes on to crash.

The answer seems to be to use std::nothrow, which looks like: [0]

  int *p = new (std::nothrow) int[5]; // gives null if alloc fails

A related question: Many C++ coding standards, including Google's, prohibit use of C++ exceptions. Do they have to use the nothrow syntax everywhere the new operator is used?

[0] https://www.cplusplus.com/reference/new/operator%20new[]/

You can also abort the program, which is what most programs do on OOM anyway.

My guess would be that they lean on the fact that "malloc never fails" [1]. Under that model, new and malloc always give you a pointer you can use, it's just that sometimes, using it will give you a segfault.

[1] https://scvalex.net/posts/6/

That blog post describes Linux's default 'memory overcommitment' behaviour. Oddly it fails to mention the term 'overcommit'.

As the post says, malloc can return null even where overcommit is used; it's not true that malloc never fails when overcommit is enabled.

Even if it were true that malloc/calloc/realloc/new/new[] could never fail on your OS+compiler, it doesn't seem wise to write code that relies on that non-standard guarantee. Poor robustness and portability.

Not a Googler, but I believe that exceptions coming from the standard library (which must support exceptions, of course…) are allowed.

Various folks working on C++ tooling at Google and e.g. Abseil have commented in talks—no, the standard library is not required to support exceptions. They are in fact disabled. Code which would throw an exception instead aborts the program.

Ah, I see that Microsoft's implementation does allow this. I wonder if you could still call that standards compliant?

The C++ requires exceptions, so with -fno-exceptions, the compiler is not standards compliant.

However, the big companies like Apple, Facebook, and Google simply don’t care about standards compliance in their internal C++ code bases. At least, not as an end goal. There are a lot of good talks about this.

Instead of throwing, you just abort the program. If you are running part of a backend service this is reasonable, under some assumptions.

If you fail to allocate memory, there’s a good chance that your process can’t continue servicing requests anyway. So, it’s a good tradeoff to abort. The client can retry later or with a different backend, and the job scheduler can start another instance of the process.

No excpetions allowed? Than using "new" is the wrong choice! Redefining the "new" operator only makes sense when you can reuse existing code, but if you must add that check for everey "new" invocation, then you are forced to parse all your existing code and using a separate function makes sense. Sorry for your colleagues, but this is not a problem with undefined behaviour: it's the original developer fault! And I'd hate if compilers were forced to restrain themselves from helping smart developers in order to please loosy developers.

I feel like I'm missing something. Even if we assume i is never 4 or 5, why can we assume that v is contained in the table? Even with undefined behavior, it seems like that's bugger compiler behavior.

By the author's logic, even if the undefined behavior didn't exist, you can still assume i is never 4 or 5, but that doesn't meant the function always returns true. Is there something I'm not understanding here?

Once the i == 4 and i > 4 cases have been eliminated, all code paths in the function return true. It's helpful to remember that the

    if (table[i] == v) return true;

line has an implicit `else continue;` clause, not an `else return false;` clause.

Ok, so because i never reaches 4, it assumes the loop doesn't exit due to the 'for' condtion, so it must return true.

That makes sense, but still feels like a broken way to do optimizations.

I don't remember what UBSan looked like in 2014, but it does something not entirely unhelpful for each of these examples, although they are caught at run time, not compile time:

runtime error: index 4 out of bounds for type 'int [4]'

UndefinedBehaviorSanitizer: SEGV on unknown addres

runtime error: reference binding to null pointer of type 'int'

> although they are caught at run time, not compile time

Not if the compiler got to it first. If the compiler does what Chen points out it can do, you won't be indexing anything at run time.

At -O0, the compiler will generally not do any of that analysis.

GCC doesn’t enable -fdelete-null-pointer-checks until -O2, so even -O1 might work fairly well.

Is that true? The compiler is being explicitly instructed to (try to) detect undefined behavior where it happens. This is the difference between tools like UBSan and tools like Valgrind. Valgrind is low-level, it’s a virtual x86, so the optimizer runs first. UBSan is high-level, it instruments the code using the compiler, and presumably the compiler can be directed to preserve the instrumentation.

I see the same errors using Clang with -O1, -O2, and -O3.

UBsan is part of the compiler, so it inserts runtime checks before the optimization passes which rely on undefined behaviour run.

Discussed at the time: https://news.ycombinator.com/item?id=7954944

Or maybe the discussion time travelled …?

Reply on news.ycombinator.com