Hacker News Reader

Comment by kps | Hacker News Reader

I have become convinced that the current screw-the-programmer interpretation of ‘undefined behaviour’ was not intended, or even imagined, by the original ANSI C committee. Within the committee's mandate to ‘standardize existing practice’, it was simply an acknowledgement that C compilers translated straightforward C code into straightforward machine code without adding safety checks, and that simple code might — in some circumstances on some machines — do very strange things.

In the Rationale, the committee listed places where they intentionally diverged from existing practice. They considered “the most serious semantic change” to be requiring value-preserving (vs unsigned-preserving) integer promotion. They didn't mention ‘undefined behaviour' at all.

During the standards process, Dennis Ritchie described the ‘noalias’ proposal as “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”. That's exactly what ‘undefined behavior’ has turned into. If anyone had foreseen that at the time, the reaction would have been the same: “Noalias must go. This is non-negotiable.”

View on HN

> the current screw-the-programmer interpretation of ‘undefined behaviour’

I don't believe that interpretation was ever followed by anyone. In C parlance, "undefined behavior" only means that the standard does not define any specific behavior for a particular case. In other words, that particular code construct isn't valid C, but the standard doesn't mandate it should be illegal because some C implementation somewhere may have a very good reason to fill in the blank.

Therefore, anyone writing code in standard C should simply not fumble around by writing code he does not know will actually do, and those who target a specific compiler implementation are required to know what the compiler actually does in that specific case (i.e., how they've defined the behavior left undefined by the standard) and proceed to know very well what they are doing.

In short, "undefined behavior" never meant "screw-the-programmer". At most, clueless programmers screw themselves due to ignorance.

Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language. The question is how difficult it is for programmers to avoid mistakes and how aggressive the programming language is in punishing programmers for their mistakes. C is terrible by these measures.

> Your argument is tautologous. Any "clueless programmer" can "screw themselves due to ignorance" in any programming language.

It appears you're missing the fact that someone needs to be completely oblivious and very foolish to expect anything out of behavior which was intentionally left undefined. I mean "undefined behavior" clearly signals that no particular behavior should be expected. A programmer needs to be particularly clueless and specially incompetent to write code that has unexpected consequences and goes against the warnings specified not only in the international standard which specifies the language in detail but also in long-standing programming references.

A programming language is not "aggressive" just because incompetent programmers decide to go against the very specification of the programming language to write broken code. Your argument is like claiming electricity is "aggressive" just because some idiot repeatedly sticks his fingers in an electrical outlets and in the process zaps himself.

> A programmer needs to be particularly clueless and specially incompetent to write code

Or just distracted. Even the best programmers make mistakes. Which is why programming language designers should attempt to make it easy to do the correct thing, and hard to do the wrong thing.

> Or just distracted.

Could you provide a single example showing how distraction alone can lead a competent programmer to write C code that relies on undefined behavior?

> A programmer needs to be particularly clueless and specially incompetent to write code that has unexpected consequences

No. That's called "a bug".

> No. That's called "a bug".

You need to actively go against the most basic aspects of the programming language you're using to force undefined behavior into your code. So, it's not merely a bug. It's the direct result of incompetence, and one which no programmer can pin on his tools or even the programming language.

> You need to actively go against the most basic aspects of the programming language you're using to force undefined behavior into your code.

Adding two ints together is potentially undefined behaviour.

Electricity _is_ aggressive in that it does not weigh in the interests of the person and just does its thing, just like C.

You can now insult and smear on people that write undefined code in C, but that does not change the fact that undefined behaviour happens in C code and is a source of problems. These problems are worth a solution besides swearing and derision.

AFAICT, the main rationale for undefined behavior in the original instance boils down to traps: any operation that could trap is undefined. In particular, this seems to motivate why signed integer overflow is undefined as opposed to implementation-defined. It should be pretty clear why it's a good thing that potentially-trapping instructions have undefined semantics in those instances (or, perhaps more accurately, have semantics that have large leeway for when, where, and if the trap is triggered).

Undefined behavior is generally nowhere near as bad in practice as it's often made out to be in practice. It's mostly a case of taking code that is manifestly wrong and making it manifest wrongly in different ways, and when you look at how and why compilers use the undefined behavior to optimize, it's hard to actually object to it. The two main counterexamples are strict aliasing (although it should be noted that most compilers will use the strict aliasing rules only if it failed to figure out aliasing by other means, so trivial things like int_var = (int)&float_var don't end up being deleted as being nonsensical) and signed integer overflow (note that wraparound semantics usually are as equally bad as undefined behavior, but making it be undefined makes it challenging to check if the operation would overflow).

Not just traps... systems level code often relies on what is by the standard "Undefined Behavior" but is in fact well defined for that implementation, something the standard allows for very good reason. At the end of the day interacting with hardware sometimes requires doing things that "No Sane Programmer" would ever do normally. Most of undefined behavior is a nice way to say that the standard is not going to try to define something that is probably an artifact of the implementation. Compiler writers can however use and abuse the fact that there is no constraints. MSVC will prune code with undefined behavior. Clang may call the never-called (only if not static or in an anonymous namespace), etc. Undefined behavior is only undefined by the standard... in most cases it has very well defined results.. for a specific implementation and hardware set.

The original ANSI C committee had no idea about modern optimization pipelines. If people had continually pushed back against undefined behavior back then, there's a good chance that by 2017 the result would have been that C would be dead, replaced by a language that allows for modern optimization techniques.

And would that be such a bad thing?

How come we have languages like Rust that achieve almost the same speed while maintaining dramatically better safety, anyway?

Because type safety makes a lot of optimizations sound. C and C++ have to use undefined behavior rules to achieve a lot of optimizations that type safe languages can more easily perform. In fact, the optimization that the article is complaining about is really only a problem because C is not type safe.

So that's my point. If C was those few percentage points slower, and died, then we'd have better languages sooner.

You're the last person I'd have expected to make that sound like a bad thing.

While benchmark games played a part in the modern ‘undefined behavior’, I'm not so sure that it would made much difference to adoption of the language. Consider Linus Torvald's well-known rant as a point in the opposite direction.

In the universe where ‘undefined behaviour’ had been clearly specified as ‘what you write is what you get’, C might have gone to consistent use of optimization-enabling annotations, following ‘const’ (and later ‘restrict’). Along those lines, ‘volatile’ was ANSI's other big mistake, as creating it broke existing code; I now think that should have been the default, with fragile-optimizable status being explicitly indicated by extending the use of ‘register’ keyword.

It's not just benchmark games. It's people's real-world code.

Look at how often folks on HN complain that the Web platform is useless because JS is slow. C without optimizations is just as slow if not slower. Compiler optimizations are so good that people don't realize how much they rely on them.

Linus was wrong when he complained about the compiler treating null dereference as undefined behavior. This is a very important optimization, because it allows the compiler to omit a lot of useless code in libraries. Often times, the easiest way to prove that "obviously" dead code can never be executed is to observe that the only way it could be executed is for null to be dereferenced.

Opt-in optimization keywords wouldn't scale to the sheer number of optimizations a modern compiler framework performs. Restrict hasn't been a success because it's too subtle of an invariant. It's the kind of thing compiler authors, not application developers, should be thinking about.

This is an important point, and it's why the "C should die" crowd is hard to take seriously. They've even started labeling people who use C as somehow morally suspect, as if we're bad people for choosing to use an unsafe language. We're knowingly putting people in danger! Right.

It's strange that the word "unsafe" has tainted people's thoughts so dramatically. Like calling torrenting music "piracy."

If one don't follow the High Integrety, CERT, MISRA standards, validated with tools like LDRA.

Or at very minimumm compiling with warning enabled as errors, with a continuous build breaking on static analysers errors, then yes.

I'm not endorsing C. Don't use C for anything you need to be secure.

I need Emacs to be secure. It's written in C. It interfaces with the internet.

Ditto for Bitcoin. It's the basis of a new financial system. The core software is written in C++.

Same for Linux. C.

Prejudice generally isn't helpful, and it's a bit strange that you can recognize C's merits while also decrying it.

I haven't been "recognizing C's merits" either. In fact, the real reason behind this problem is that C is not type safe, so optimizations (such as the one in this very article!) that are perfectly fine to do in type-safe languages are not possible to do in C without aggressively "exploiting" undefined behavior.

But sometimes these checks just seem to end up entirely removed, and that is just not OK: I have been a developer working on performance constrained system software in low-level programming languages (including heavily optimized games written in C++) and this undefined behavior idea has gone way way too far. I can always make code faster by removing checks I don't need manually: trying to compare the small gains here with "let's just use node.js lol" is dishonest.

C++ states stuff like references must not be NULL and "this" must not be NULL, but in the real world it is possible for a NULL pointer to be dereferenced into a reference and for a method to be called on that reference and for the method to complete execution without the app crashing. Yet, some C++ compilers are now insisting that "this == NULL" checks (which is the most hilarious case, but simple "&ref == NULL" are the same) and all the dependent code be entirely removed, hamstringing runtime safety and sanity checks.

What works for me is when the compiler says "for this to happen the code would have had to crash"; but what does not work for me is "for this to happen the code would have to be violating the specification" as the entire point of NULL checks in a program was always to check for invalid execution and mitigate its effects :/ and yet since this code has never crashed on any reasonable C++ compiler the only way to check for it is to add comparisons that are now being removed under some misguided assumption that the code would fail at runtime.

The proper place to put those checks is before the undefined behavior would be invoked, not after.

These optimization opportunities aren't small gains. They have big consequences, for example when they cause code that would not be vectorized to be vectorized. Again, compiler authors don't add UB optimization for the fun of it. Patches to add theoretical optimizations that don't actually move the needle are routinely rejected from LLVM and GCC (as they should, because optimizations slow down compilation, so they need to pull their weight). Rather, they add UB optimization when code is shown to benefit, often the code that people come to their bug trackers with complaining that it doesn't optimize to what they expect.

If there were a simple and reliable way to say "make the program crash if we hit any of this UB, rather than optimising it completely away" I think that would make a lot of people happy.

LLVM already does this as much as possible. Look at how Clang inserts "ud2" instructions in dead code paths.

Is there a way to use that to address the "NeverCalled" example?

I feel like there's a huge disconnect here. Even after the strange behavior is explained, some people say "wow, I never ever want that behavior, how do I reliably avoid it?" but others respond "there's no problem, you're just using it wrong".

Is there really no way to satisfy both sides?

Look at how often folks on HN complain that the Web platform is useless because JS is slow.

I haven't actually seen anyone complaining about that. Do you have any links?

There are some specific complaints like: JS can't do 64-bit arithmetic or SIMD; but that's only really needed for games and scientific computing, which don't need to use JS. Or that JS is single-threaded; that's a fundamental feature of its design, nothing to do with optimisation.

C without optimisations is just as slow if not slower.

Nobody's talking about taking away all optimisations, just not trying to do extreme optimisations that exploit undefined behavior (or rather, assume it can never occur).

Plenty of C compilers worked that way in the 90s and performance was perfectly acceptable (on hardware with a fraction of the speed and memory of today's computers and phones).

Modern C++ probably relies on a higher level of optimisation, but that's another story.

> Nobody's talking about taking away all optimisations, just not trying to do extreme optimisations that exploit undefined behavior (or rather, assume it can never occur).

Those "extreme" optimizations are usually just surprising behavior that emerges from perfectly reasonable optimizations. For example, assuming that code that follows null dereference is dead is important.

> Plenty of C compilers worked that way in the 90s and performance was perfectly acceptable (on hardware with a fraction of the speed and memory of today's computers and phones).

You can get that experience with GCC -O0. Do you want to run code like that? I don't, and neither do customers.

People who don't work on modern compilers often think that there is a subset of "simple" optimizations that catches "obvious" things, and optimizations beyond that are weird esoteric things nobody cares about. That isn't how it works. Tons of "obvious" optimizations require assumptions about undefined behavior.

If I could get that on -O1 or -O2, or maybe -Os, I would very happily do so. (But I don't actually know what optimisations those entail without poring over the manuals.)

You're implying that 90s compilers had no optimisations, which is incorrect.

Why is this a hot topic now, and why was it not a hot topic 10 or 15 years ago?

I suggest that something changed in the interim, and that what changed is the addition of dangerous optimisations. I'm not sure where it all started but strict aliasing in GCC is a potential candidate.

As others have pointed out, GCC and Clang seem to have by far the most horror stories, even though they don't actually generate the fastest code. I imagine that's mostly because GCC and Clang are so widely used, though.

I don't see how it's an optimization to assume, at compile time, that a static pointer that is always null is actualy aiming at the function NeverCalled. Why not pick some other function, like one which prints a diagnostic and calls abort?

It's not aiming at the function NeverCalled; it's aiming at EraseAll.

As the article states, if a local static function has exactly one assignment to it, then it can be an important optimization to assume that it will always have that value. Imagine that it's some kind of "DebugPrintf(...)" function that, in release builds, is always set to a no-op that does nothing before being called. You would definitely want that indirect function call to be inlined to nothing in release.

For debug functions that completely disappear in release builds, we have inline functions with conditionally empty bodies or old-school macros.

It is a (decades ago) Solved Problem.

Sounds like win-win to me!

C would be dead.

We will have a sound low-level language suitable for optimization.

Now, if we throw in C++ eradrication...

It would have been much more prudent if the committee defined the behavior in a way amenable to optimization, rather than asking for a blank check.

They did. "Undefined" doesn't mean "unconsidered by the committee", it means "do what you must for optimization".

What language do you think would have replaced it?

It seems to me that C had already won as the de facto systems language, long before any of these "modern optimisation techniques" cropped up.

Optimisations that make it harder to use the language safely are downright dangerous in my book.

I would have been happy with Modula-2, Ada or Object Pascal as basis.

But better yet would have been Modula-3 or Active Oberon.

I hear very good things about Ada, aside from its unfriendly old-fashioned syntax.

Some of us do enjoy verbose explicit syntax instead of hieroglyphs. :)

Quite helpful when maintaining unknown code in big corp projects.

As others have said, if C were dead by now that would be great.

But I'm pretty skeptical, to be honest. I've been working on one or another high-performance C or C++ program for most of the past 20 years. I can't ever remember getting a really substantial speed improvement from upgrading the compiler for an important platform, because anything the old compiler did badly that really hurt program performance had already been avoided, either before or after seeing it in profiling results. I'm sure that if you took C code developed on a modern compiler and compiled it with a 90s compiler, it would be slower. But I doubt the software ecosystem would actually be drastically slower if optimizer technology hadn't advanced significantly since 1995, and everything had been developed under that constraint. And I don't think every single advance in optimization since 1995 is dependent on degenerate transformations of undefined behavior.

> I have become convinced that the current screw-the-programmer interpretation of ‘undefined behaviour’ was not intended, or even imagined, by the original ANSI C committee

Does it matter today what the original committee did or did not intended? I might even invoke the old adage "the road to hell is paved with good intentions"; the best would be to learn the lessons from their failures when designing new languages.

This, just so much this!

I've been longing for a C compiler with a "sane optimizations only"-switch like forever. I'd gladly give up on the additional couple of per cent speed improvement obsessive compulsive compiler writers managed to eke out by ignoring the source codes' obvious intentions and defending it with "but technically it's undefined behaviour"!

What would that look like? How would this prevent me from returning a pointer to a stack frame that no longer exists, just for example? Clearly undefined behavior, but C doesn't seem capable of expressing this safely, with or without the compiler's help?

It wouldn't make it safe; it would make it so that the consequences of returning that pointer are just the same as if you had written an assembler routine returning that pointer. On all common hardware, that would be none if the pointer is never used; on most common hardware, it would be none if the pointer is never used in a call at least equally deep — but anyway, you'd get whatever the machine does, and if you don't like it, that's your problem. In pre-UB C, the ‘spirit of C’ that C89 was intended to maintain was that you get what you wrote.

By contrast, modern ‘undefined behaviour’ means that if you return that pointer — even if it is never actually used — the compiler can throw away all the code leading up to that point (including external side effects) on the grounds that it “can't happen”. You get much less than what you wrote.

Are you sure about that? Can you point to a clause in the standard?

What may certainly cause the behavior you describe, though, is creating a pointer to an out-of-bounds element of an array.

How would this prevent me from returning a pointer to a stack frame that no longer exists, just for example?

It doesn't, but the outcome would be predictable: the pointer will always be pointing there.

I assume you mean by "stack frame that no longer exists" something like returning a pointer to a local variable; what that would do is return the address where the variable was --- the memory address still exists, so "no longer exists" is somewhat of a misconception here.

What "sane optimisations" mean is that the compiler won't e.g. decide to remove all the code following any call to that function, just because you "invoked UB".

Is that really such an improvement?

Maybe you won't quickly find a practical and non-contrived application for this specific case, but there are plenty of others. UB breaking buffer overflow checks springs to mind.

There's some discussion about that here https://blog.regehr.org/archives/1287

Everyone posts a comment like this every time undefined behavior surprises someone. But the reality is that the reason why C remains alive is that compiler writers have managed to make it fast. It is not "a couple of percent": these kinds of optimizations can make an enormous difference when, for example, they're the difference between vectorizing a loop and not doing that.

Compiler writers are not "obsessive compulsive". They respond to the demands of their customers. Frequently, the reason why these optimizations exist is that someone filed a bug asking "why doesn't the compiler do this seemingly-obvious optimization?" Often, the only reason these seemingly-obvious optimizations work at all is by exploiting undefined behavior.

The craziness for C optmizer tricks is in many cases plain phsycologic.

As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome.

Actually there is a remark from a famous compiler write (female), which I don't recal the name now, that C brough back into the stone age what the optimizers were already able to do for Algol family of languages.

This is visible in PL/8 research paper, a compiler that already used compiler optimization passes in the 70's, nowadays mostly common on LLVM.

Can you give some examples of optimization passes in clang/LLVM that you think are unnecessary?

I didn't say they aren't necessary, rather that the idea was already used in PL/8 during the 70's, a type safe safe systems programming language.

https://courses.physics.illinois.edu/cs426/fa2017/Papers/pl8...

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.87.4...

Could it be Fran Allen, the one with the Turing award? But I can't find the comment with google, so maybe not.

Yes it was her.

The statement is actually part of the "Coders at Work" interview, where she explains why "how C has grievously wounded the study of computer science." from her point of view.

http://www.codersatwork.com/fran-allen.htmlhttp:

> As an example, it doesn't matter that it does in 5ms what it takes to do in 15ms without the optimization, if in the end anything less than 20ms doesn't have visibile outcome.

That hasn't been true ever since power consumption started mattering.

If it really mattered at that level, people would have already stopped trying to do Web based OS or applications for mobile phones.

Also Apple, Google and Microsoft would expose the complete set of mobile and watch OS APIs to C and C++ developers, which they don't. They are kept down to the bare minimum for the upper OS layers.

If you mean takes 15ms vs 5ms to compile yes. However if you're talking executions speed those low hanging fruit optimizations were picked in the 1980's. What we're talking about here are optimizations that speed up some obscure benchmark on a disused architecture by 5%. Bonus no telling if performance is worse on next years silicon.

So now the compiler should also statically figure out how long some code is going to take to run?

Chances are I want the compiler that gives me a binary that does its job in 2 hours rather than 6.

Everyone posts a comment like this every time undefined behavior surprises someone.

Yes! Because it's terrifying, and the explanation is not reassuring.

How do you know it would only be a few percent? What if such a switch made your code ten times slower? Without actually reading the clang code and seeing what all the optimization passes do, I don't see any a priori reason for assuming it would be a few percent rather than 10x.

Reply on news.ycombinator.com