Hacker News Reader

Comment by dvt | Hacker News Reader

The nested function execution interleaving blew my mind (imagine having to debug that), so I had to look it up. Apparently, interleaving is prohibited in C++17 onward. So this:

> The second one is there since this is C++, priority() might raise an exception, meaning that new Widget will be called, but never passed to std::shared_ptr, and thus never deleted!

Is now impossible (thank God!). See a full SO discussion here[1]. Stuff like this makes me so happy I don't write C++ anymore, but the gist of it is (from the standard):

> For each function invocation F, for every evaluation A that occurs within F and every evaluation B that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any), either A is sequenced before B or B is sequenced before A.

[1] https://stackoverflow.com/questions/38501587/what-are-the-ev...

View on HN

In three decades' use of C++, of all generations going back to original cfront, I have never encountered any difficulty, confusion, or actual problem arising from this phenomenon. It is a favorite of language lawyers and people borrowing trouble.

Agreed. This code just looks weird to me. Throwing from a constructor? Holding the result of new() in a temporary? This is just asking for trouble.

Another favorite “criticism” I have of C++ goes along the lines of “but someone could overload operator+ to be division!” I have only seen that as a contrived critic’s example, or a joke.

> Throwing from a constructor?

Actually, that’s what you are supposed to do, as this is the only way for a constructor to let the caller know that something went wrong.

There is always the option to expose the "fallible construction" as a factory function instead of a constructor. Then you can return errors as needed.

And then every object has one more state.

You mean the factory function has to return some invalid state of the class? Not so.

The factory could return std::optional<Foo> or std::unique_ptr<Foo> or std::variant<Foo, Error> or absl::StatusOr<Foo> .

Your program will still have as many possible memory states as if you had a bool m_isValid; in your type - as now you don't store a Foo but an optional<Foo>.

It's an improvement in terms of code reuse but not in semantic simplification basically.

You realise you can just unwrap an optional after checking it’s not nullopt, right?

Not if it's part of the state of your app ? E.g. a struct member. It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975

>Not if it's part of the state of your app ? E.g. a struct member.

I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j

Also there's opt.value_or() which can use a default value in the case opt is nullopt.

>It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975

I think remram's goal was to avoid exceptions. So this is a criticism of remram's goal rather than the method to achieve that goal.

Also, std::optional can integrate with exception-producing code because opt.value() throws an exception if opt is nullopt.

> I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j

And now you have to do this for every type that have some amount of preconditions. I don't understand in which universe this is sane - more code == more bugs.

e.g. here's what one would write with exceptions: https://godbolt.org/z/evMsh6383 (and, to be honest, if one is writing e.g. a command-line tool and not a reactive gui app, most likely https://godbolt.org/z/eW8YM5Gz4 as your OS will catch the thing anyways and then it's just a `coredumpctl gdb` / "open in debugger" away) ; you get the same guarantee of never having an invalid Foo but at much less mental cost.

It also prevents you of having aggregates as all the "parent" owner class will need their own wrapping in optional + private ctor, in case a sub-sub-sub-sub field would fail.

e.g. given

    struct DomainObject {
      Foo mainFoo;
      Foo secondaryFoo;
      int whatever;
    };
    struct GameState {
      std::vector<DomainObject> objects;
    };

now you can't just do DomainObject{initForMainFoo, initForSecondaryFoo, 123}; or DomainObject{.mainFoo = "", .secondaryFoo = "", .whatever = 123}; anymore, even less GameState{{DomainObject{...}, DomainObject{...}}; which is how modern C++ is meant to be used

Exception handling may indeed end up with less code, but often it is because the developers forgot to handle most error situations properly. And that's my biggest gripe with exceptions, particularly the unchecked ones, which can just pop up from 100 layers below. I've just seen it too many times when developers just throw exceptions and let them bubble up to a place where there is so little context that the final error message presented to the user is near useless.

On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless.

IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.

> I've just seen it too many times when developers just throw exceptions and let them bubble up

but it's the whole point ! that's exactly why exceptions are good !

> to a place where there is so little context that the final error message presented to the user is near useless.

there are only two valid cases: there's an error that you know you are able to recover from, you did recover, and the users does not see a message and never knows that an error happened, OR the user sees the message "The program has encountered an error. A backup of your data has been saved in c:/foo/. The program will now exit.".

Anything else makes software terrible to use. If you have logging and recovery to do, use your logging architecture and core dumps, don't misuse exceptions for that.

> On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless.

Except what happens in practice is that people just put panics everywhere because most of the time there is no meaningful action one can take at the layer where the implementation happens. Actual examples in servo: https://pastebin.com/0DAFU9vS

I also invite you to run the following command:

    $ cd ~/.cargo
    $ rg panic! | wc -l

I get 2987 as a result. Choosing to program like this instead of using exceptions which at least can be recovered by the person who will use your lib, is literally hateful towards users.

I've not seen Go code to be meaningfully different either.

> IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.

Sure, this is the community consensus in C++. It's the Python people who use exceptions to get out of for loops :)

But the most important rule is that - invalid state must not be representable in the program. There must be no way to get an "invalid" object (unless the object being invalid is part of its possible domain, but this is exceedingly rare when one isn't interfacing with a 1985 C API)

> but it's the whole point ! that's exactly why exceptions are good !

Good for what? For crashing the program with a stacktrace? Probably. But for regular error handling - that's a terrible thing. They break normal control flow by adding a parallel / alternative control flow. Now with them you have to think on what happens if any of the code you call suddenly throws an exception and the number of potential control flow paths increases drastically. They are not referentially transparent and it is nearly impossible to do functional programming with them (they introduce side effects everywhere). You can also end up in a really bad situation when a destructor throws (typically crash).

> I get 2987 as a result. Choosing to program like this instead of using exceptions which at least can be recovered by the person who will use your lib, is literally hateful towards users.

But panics are Rust equivalent of exceptions. That's the whole point of them. They are used for exceptional cases, which are impossible to recover from (which means the only way to deal with is to dump core and terminate) and most of the time preventable (you can always avoid dividing by zero or going out of array bounds).

It looks like we agree they should not be used for regular errors, like e.g. file not found. I'd not like my word processor to terminate with a core dump when it couldn't load the file from the disk. In this case return values are way better error handling mechanism.

> invalid state must not be representable in the program

Returning an option/try/either strikes that goal just as well as exceptions.

You can recover from panic! in Rust on the thread level.

Yeah, I know I can recover, that's why I said they are equivalent of C++ exceptions (which can be caught as well). But this is not a recommended idiomatic way of handling expected errors, e.g. input errors, improper configuration, I/O errors etc.

> And then every object has one more state.

No, not really. Either the allocation followed the happy path, or one of the expected failure modes kicked in.

And the supposed footgun example boiled down to failing to handle one of the failure modes.

I mean, think about it: std::make_shared is a factory method, isn't it?

Not always, e.g. not if your class includes a member that is a reference (and, say, aggregate initialization is not allowed for one reason or another).

It seems to work for me: https://godbolt.org/z/68s8qsP6K

That's an option, but now you're using a factory method instead of a constructor. It's a valid choice, particularly if you want to go for exception-free style - but GP's main point was that throwing from a constructor is not only not a footgun, it's actually the correct practice if you're writing RAII style.

That doesn’t compose in a class hierarchy, though.

That's a good point... You might be able to work around that using a template function factory e.g. `make_foobar<ChildrenFooBar>()`. I'm not sure what's a good pattern here, I don't write much C++.

As long as the every element of the hierarchy is noexcept-movable it still composes. It is just very cumbersome.

You can also use out parameters to tell about errors.

This won't work with third-party callers.

When doing that the better approach is to use a factory function wrapping this.

However mind that if you don't throw from C++'s perspective the object is fully created, so that the destructor will run.

If you throw an exception from the contractor, the object won't be fully created.

In practice I have not found that running destructor is problematic. In many cases the destructor is the default one that just destructs the fields. When the destructor should be non-default the constructor can leave the object in the move out state either explicitly or via hacks like using T tmp(std::move((*this)) on the error return in the constructor.

Throwing from a constructor is a fundamental way to make it impossible to construct invalid instances of a class. It's great, especially for immutable classes. Throwing from constructor + immutability = no invalid states ever.

> Another favorite “criticism” I have of C++ goes along the lines of “but someone could overload operator+ to be division!” I have only seen that as a contrived critic’s example, or a joke.

Yeah there's definitely criticisms you can throw at C++, but this always struck me as stupid. You could also write an `add` method that divides in Java.

I've never liked the idea of 'operators' in the first place, tbh. Scheme opened my eyes in that they're all just procedures. And then with Smalltalk and Scala I saw that they can all just be methods as well.

I've actually run into this problem before. You just haven't, is all.

I really doubt this sort of hypothetical source of memory leaks was either significant or its root cause could be pinned to this. As this hypothetical scenario depends on an exception being thrown, your code would need to throw exceptions repeatedly for the memory leak to be a problem. If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem then you have far more serious problems to fix than discussing language lawyer corner cases.

> As this hypothetical scenario depends on an exception being thrown

It doesn't.

Exercise for the reader: detect evaluation interleaving without exceptions.

> If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem

It need not manifest itself as a mere memory leak.

Exercise for the reader: make something happen beside a memory leak.

> It doesn't

Yes it does. Of course you can detect different evaluation orders using side effects, but the fact that evaluation order is unspecified isn't generally a problem: if you write code like `a() + b()` and a() and b() has side-effects that depend on the order they're evaluated in, that is just a bad way of writing code. In any language.

The point here is that the compiler is allowed to interleave subexpressions of the two different arguments which causes a memory leak in seemingly safe code. That is a very unreasonable thing for the compiler to do, which is why it is a footgun. But not that it can ONLY happen if the second function throws in between the construction of the object with "new" and the construction of the shared_ptr: if the second function doesn't throw an exception, the construction of shared_ptr is guaranteed to happen.

Incidentally: those "exercise for the reader" comments are incredibly obnoxious.

> isn't generally a problem

generally is the key word here.

> if you write code like `a() + b()`

The code doesn't have to look like that. Add e.g. some arguments...

I've frequently run into a variant of this:

    f(**x, g());

The number of stars evaluated before 'g()' (0, 1 or 2) varies between compilers, and the program I was working on would break if only one * was evaluated before g.

Order of parameter eval is UB in plain C

It is unspecified, not undefined.

Thanks for the correction. What does it mean?

If it was undefined, then anything could happen (nasal demons), but that would be silly: you wouldn't be able to safely call functions with multiple side-effecting arguments at all.

Unspecified means that you can't rely on the order of evaluation. "Anything" may not happen; the compiler controls the sequencing.

The order of parameter evaluation is not specified by the standard, so if your program behavior is relying on it it may be incorrect. But relying on it doesn't instantly make your whole program completely meaningless, nasal demons and all.

> Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine.

> Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer). [ Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. —end note ]

"Unspecified behavior" means something correct will happen, but you don't know what (in that case you can't rely on the execution order). "Undefined behavior" means something entirely incorrect may happen (crash or totally unexpected and bad behavior, so the term "nasal daemons" which means dragons coming out of your nose).

> Is now impossible

I don't see how that is so. C++ 17 allows new Widget to complete and then the priority() call to execute and throw before both are passed to shared_ptr(), thus creating a leak. Your cited example [1] doesn't leak because both arguments are shared_ptr. Seems to me that C++ 17 does indeed solve this latter case but not the former.

> both are passed to shared_ptr()

priority() is not passed to shared_ptr(), only to processWidget().

Per [1]:

> evaluations of A and B are indeterminately sequenced: they may be performed in any order but may not overlap: either A will be complete before B, or B will be complete before A. The order may be the opposite the next time the same expression is evaluated.

And:

> 21) Every expression in a comma-separated list of expressions in a parenthesized initializer is evaluated as if for a function call (indeterminately-sequenced)

Emphasis mine. What the above basically says is that in the case of some function `f(A, B)`, the arguments `A`, and `B`, are what's known as "indeterminately-sequenced" -- this mean that their execution cannot be interleaved (overlap) -- but they still individually execute in a non-deterministic order (A before B, and sometimes B before A)!

With that said, the good news is that B can now never throw in the middle of A, which is precisely what we have in OP's example.

[1] https://en.cppreference.com/w/cpp/language/eval_order

Whew thanks for looking this up! I was afraid I'd have to add yet another entry to my gigantic C++ footguns.org document. It's getting so big now that Emacs struggles a bit to load it due to inline code examples!

At first I thought that was a domain and not an org file. :)

Looks like footguns.com is taken but footguns.org is still available.

Gotta register a 501c3 to help save poor C++ programmers from the many footguns. Donate today!

Your footguns.org file legitimately sounds like something that other C++ programmers would find useful. I for one, being a rank novice at the language (despite attempting to use it for the last ten years!), would certainly appreciate a reference like that.

Most of it is basically from cppcon talks and Scott Meyer's books, but the advice I basically give to incoming C++ programmers today is this:

* Start with C++20 unless you have a very good reason not to. Not only does it obviate crufty old things like SFINAE (concepts!), but it includes a ton of usability fixes (e.g. reflexive operator== -> I only have to write the code for MyType == MyOtherType in order to get both that version and MyOtherType == MyType). A lot of lambda behavior has really been cleaned up too (e.g. capturing `this` has fewer corner cases).

* start with Google's coding guidelines [0], as they've been developed to avoid many footguns (the bottom line depends on it). Once you understand things better, keep removing these rules (e.g. about exceptions, const& parameters; many of these rules are good for big teams, but annoying to follow for individuals)

* The CppCon "back to basics" talks are absolute goldmines, and the speakers usually tell you if some technique has been outdated as of the recording. Some things in certain books, although valuable, may be outdated based on later revisions to the language.

* The best notes to take are usually some structure list followed by a bunch of godbolt links with examples, e.g. this one I made to demonstrate the reflexive operator== behavior [1]

[0] https://google.github.io/styleguide/cppguide.html [1] https://godbolt.org/z/scPdcaWT7

I will do that when I am done reading Java Puzzles and JavaScript the Good Parts.

OK, I must have mistaken what the original was, because I thought it was like this:

processWidget(new Widget, priority());

I think I saw the above code elsewhere.

IIRC, this may also leak when `priority()` throws due to evaluation order. (Not exactly sure now, as I now always use `make_shared` whenever possible.)

However in the Effective C++ example, the `shared_ptr` constructor gave a false sense of security as it seemed the `new`-ed `Widget` was always managed by the smart pointer from its allocation.

I always wonder if compilers actually do weird optimizations taking advantage of semantics like those.

Another example is when undefined behavior occurs, like (iirc) signed integer overflow. Compilers can technically do anything they want, including weird things. But how often does that actually happen?

Different architectures have their own function passing convention. It’s convenient to evaluate left-to-right, pushing as you go, if that matches the arch. And vice versa.

That would explain why you want it implementation-defined, but leaving it indeterminate means that the same piece of code is allowed to have different evaluation orders each time it is encountered. This is much stranger, and very specific to C and C++, I don't think there is any other language that doesn't specify the order of execution.

Haskell? Expressions have to be evaluated in order to evaluate expressions that depend on them, but otherwise the compiler is free to decide the order of evaluation.

> In this case, it's pretty easy to see that 3 will have to be printed after both 1 and 2, but it's unclear whether 1 or 2 will be printed first. The reason for this is evaluation order: in order to evaluate one + two, we'll need to evaluate both one and two. But there is nothing telling GHC which of those thunks should be evaluated first, and therefore GHC is at full liberty to choose whichever thunk to evaluate first.

https://wiki.haskell.org/Evaluation_order_and_state_tokens

Well, Haskell's lazy execution model and implicit purity makes this far different from C++. The examples there all rely on the guarantee-breaking unsafePerformIO, while in C++ you can break your program with perfectly safe,c normal C++ code, such as creating a shared pointer and throwing an exception.

Note that in Haskell evaluation order is not guaranteed anywhere, even between separate statements, whereas in C++ it is basically guaranteed everywhere except function calls.

unsafePerformIO was there to make the indeterminate evaluation order visible, but isn't what causes that indeterminate evaluation order. You are right, though, that for 'safe' Haskell code the evaluation order shouldn't matter, although it is sort of a matter of convention; 'head' is unsafe, but is presumably now permanently stuck in the language, while on the other hand perhaps one could write C++ without exceptions, but that wouldn't be 'normal' C++ code.

Sure, my point was that, as far as I understand, even Haskell code that performed IO would have a well-determined order, if it was doing normal IO; whereas C++ code that does something as simple and safe looking as foo(i++, i) may produce different results in different runs (it was even UB before C++17, and still us in C; and even other common idioms, such as function chaining, had undefined execution order).

Yes and no. The order IO is performed is well-defined (that's the purpose of the IO monad), but the evaluation order is not (apart from ordering arising from data dependency), and this is the case with or without unsafePerformIO. You just won't get any different behaviour with safe Haskell code, and Haskell is very much on the safe side of things, so even though the order of evaluation may be indeterminate, you would never notice it (maybe a timing attack is possible?). But this is admittedly hair-splitting.

If you think about how it interacts with inlining, it's easy to see how optimizers like this freedom. Suppose there's just one call that may throw and the others are pure functions. The compiler could bunch the pure ones together to optimize register and stack allocation.

This is the correct answer, plus add loop unrolling etc.

It is simply not possible to write an optimizing compiler in which the evaluation order is truly indeterminate yet always the same.

I was claiming it could be left implementation defined instead of unspecified. That way, code for particular platforms could be evaluated in different order, but it would always be deterministic for a particular compiler.

The optimized evaluation order would depend on the situation near at the call site, not the architecture or platform.

The GP that my post was replying to was claiming it was arch dependent, and I was pointing out that, if it had been, they would have likely not left it unspecified. So, I think you and I are in agreement.

I would be truly shocked if this optimization ever mattered in practice. It would mean that rewriting code from

  {
    auto& a = <expression>
    auto& b = <expression>
    foo(a, b);
  }

  foo(<expression>, <expression>);

Could be an optimization.

Edit: modified the code a bit to make the two samples more similar.

During the standardization of C++17, a proposal specifying the left-to-right order of evaluation of parameters (and other operations) came up and the committee got very close to accepting it, but in the end there were concrete examples in actual code that was worse of because of the proposal, so it was unfortunately weakened at the last minute.

Looking at the proposal in question [0], it seems very sad that the alternate, not recommended, choice was made instead [1] , especially since the reasoning seems to have not been put down in writing anywhere. The paper does mention that the difference in performance was <4%, with both improvements and worsening being seen by the VC++ implementers.

[0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3....

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...

Why shocked? Certainly a micro-optimization, but order of things often matters if the compiler cannot prove it's safe to speculate about the execution order. Maybe the surprising thing here is the theme of TFA, that the order of argument evaluation is not defined.

Given the out of order nature of processors, and the relatively limited scope for complex expressions given as function arguments, I would not expect this to matter in real-world programs. It seems this was also the opinion of the people drafting the new evaluation order changes [0] in C++17:

> We do not believe that such a nondeterminism brings any substantial added optimization benefit, but it does perpetuate the confusion and hazards around order of evaluations in function calls.It perpetuates unnecessary confusion around brace-initialization vs. direct initialization using parenthesis.

> We found that some entries in the benchmark suite ran slower, others ran faster compared to the scenario where the evaluation of the argument list is left unspecified. The variation is between -4% and +4%. It is worth noting that these results are for the worst case scenario where the optimizers have not yet been updated to be aware of, and take advantage of the new evaluation rules and they are blindly forced to evaluate function calls from left to right. It is clear that the left-to-right evaluation strategy is triggering new optimization paths (different inlining decisions and different register allocation) affecting the variations in the benchmark performance. It appears those opportunities have not traditionally been exploited, even though permitted under the unspecified order regime.

Unfortunately, they seem to have been overruled by the Core Working Group [1], for reasons I have not been able to dig up.

[0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3....

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...

The answer is yes. Compiler authors absolutely take advantage of these things for optimizations.

As for paranoia about undefined behavior? Compilers won't emit a program to call you a pizza or format your disk. There are risks, but those aren't real ones.

A bit of a nit - your storage driver could absolutely emit a program that formats your disk due to undefined behavior.

If you already have a problem that contains instructions that are manipulating your disk in these sorts of ways then this is within some reason. But the usual hyper-concern about UB is that it'll take a program that otherwise does completely different things (imagine some CLI utility that just reads from stdin) and instead produce some maximally adversarial program that ruins your life. This ins't a real concern.

Agree :)

Most optimization uses of UB that I've seen is to take full liberty to remove branches and instructions. For example, if the result of UB is used in a comparison, the compiler is free to pick whichever side of the branch (even inconsistently) and elide. It is actually quite common with for example loop unrolling and vectorization (ignoring signed overflow of the indvar is a huge boon)

In fact, the compile is free to assume that the comparison itself will never happen and not emit any of the paths.

If you write something like

    int a;
    ...
    int b = a
    if (a + 1 > b){
       foo();
    }

Then compilers will use the fact that integer overflow is undefined behavior. This allows the compiler to assume the `if` statement will always be true. And hence it removes this check.

This isn't just the compiler removing a check the programmer wanted. This could occur because of constants, where other constants make the check meaningful. It could also occur after in-lining a specific function call.

Really, the only case where this optimization would be bad is if the author was trying to detect overflow. Sadly, detecting if something would cause undefined behavior in C code is hard. Because you cannot try the thing.

Others have mentioned that compilers take advantage of these things for optimization, but haven't mentioned that compilers will still often do unexpected things when encountering UB with optimizations off.

Turning optimizations on doesn't suddenly undefine any behavior, it just changes what the compiler does when encountering some of those behaviors (among other, non-UB based optimizations). A non-optimizing compiler and an optimizing compiler both have to conform to the standard.

There was a post here not too long ago about how C/C++ compiler writers have consistently taken the wiggle room of "undefined behavior" to do terrible, terrible, damage to otherwise fine code. https://news.ycombinator.com/item?id=27221552

In this case there is no undefined behavior, the order is just unspecified.

> unspecified

how is that different from undefined?

The existence of undefined behavior indicates that the program is invalid. Unspecified behavior is just something that is not precisely defined.

Undefined behavior is unbounded in both space and time in terms of program semantics, that is, a program that will engender undefined behavior may do so at any point during the course of program execution (unbounded in time) as well as may be observed within any memory region (unbounded in space). A colloquial way of saying this is that a compiler is free to do anything it wants anytime it wants in the presence of undefined behavior.

Unspecified behavior is bounded both in space and time. Unspecified behavior may only affect program semantics within the statement in which it is engendered and may only be observed within the region of memory that is written to or read from.

It is often said that undefined behavior is invalid, and one can sympathize with that statement as it's commonly repeated, but it's not true. All the standard says about undefined behavior is that the standard imposes no requirements about program behavior, it does not state that the program is invalid or that the program must behave in some kind of invalid manner. Almost all non-trivial C++ programs engender undefined behavior in a manner documented by the compiler and do so in a safe and principled way.

In English, that's a reasonable point but within the C++ standard behaviour is declared to be specifically undefined in the text - that is to say, we are telling you, you may write this construct however said construct is not C++

Note that this post was heavily discussed and disputed. The question "is undefined behavior treated correctly?" is rather contentious.

It certainly is the case that most compiler writers have decided this is okay. And I personally tend to agree with them.

Reply on news.ycombinator.com