Hacker News Reader

Comment by _kst_ | Hacker News Reader

The author claims that:

> In C89, undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you must define what the behavior is in your implementation, and there are a few permissible options”.

That's a serious misinterpretation. C89 says that "Permissible undefined behavior" includes "ignoring the situation completely with unpredictable results". There is absolutely no requirement to document what those "unpredictable results" might be.

The standard joke is that one possible consequence of undefined behavior is making demons fly out of your nose -- not because that's actually possible, but because actually making demons fly out of your nose would not violate the standard. That's equally true in C89 and all later versions of C. The change in C99 from "Permissible" to "Possible" made no difference. The phrase "imposes no requirements" has always meant exactly that. (And if you think the change from "Permissible" to "Posisble" is semantically significant, then it would have been a recognition of what was already accepted.)

The idea of "nasal demons" goes back to 1992. http://catb.org/jargon/html/N/nasal-demons.html

View on HN

I came here to say something similar. The author says:

This is wrong. That is the meaning of what C89 calls “implementation-defined” behavior. The implementation gets a choice; the standard may lay out what the choices are, and in any event the choice must be documented.

But with C89's “undefined” behavior, all bets are off. Numerous examples are documented of cases where real compilers were forced to behave in utterly bizarre ways because of real hardware limitations.

The C standard is quite liberal in its use of undefined behaviour.

Some cases are due to conflicting existing implementation that predated the standard. (Though implementation defined might make more sense?) Some are for performance reasons.

And some are utterly bizarre, like some things that should be syntax errors instead being declared undefined. If memory serves right, that includes eg not closing your string literals. (Thankfully, all implementations I know give you an error message.)

I have two responses to that. The first is that I think your specific example is mistaken. The C89 standard mandates a diagnostic message “for every translation unit that contains a violation of any syntax rule or constraint” (2.1.1.3). It also specifies that a string literal is a sequence of “any member of the source character set except the double-quote ", backslash \, or new-line character” (3.1.4). So my reading is that an attempt to include a newline in a string literal is a violation of a syntax rule that requires a diagnostic, and is therefore not undefined behavior. But I am far from an expert, and I would be glad if you could correct me if I have misunderstood.

But my second point is, the people who wrote the C89 standard were really smart. They were compiler writers from many areas of research and industry and worked very hard to find a workable compromise between all of their conflicting needs. It has often happened that I've seen someone say something like “an unclosed string shouldn't be undefined behavior, it should be a syntax error”, and then someone from the committee would show up and say “we wanted to make it a syntax error, but we were supposed to codify existing practice. Widely-Used Compiler X didn't diagnose that, and in fact couldn't, because of …”. And the reason would be something I couldn't have thought of. So I have learned to give them the benefit of the doubt, because they know way more about it than I ever have or will.

Thanks for the learned response!

I just did some research, and https://stackoverflow.com/a/367662/590534 has a good overview over undefined behaviour on the syntax level.

Oh, I don't doubt that the standard authors were smart, and worked within the constraints that were prevalent at the time. Their justified genesis doesn't make the outcomes less bizarre.

(And especially for C++, most of the later features are essentially workaround for bad ideas they had earlier.)

For the running example about unclosed string literals, I wonder why they didn't make it at least implementation defined behaviour instead?

The standards also seem a bit split in their purpose: on the one hand, they often try to codify existing behaviour. On the other hand, they often introduce new features that take compilers years to implement. (That probably applies more to C++ than C.)

With the benefit of hindsight, lots of problems could have been avoided if C had come with a module system a bit more sophisticated than automated copy-and-paste of include files via the preprocessor.

GCC has lots of flags to give you slightly different dialects of C. The Linux kernel for example tells GCC to never elide null pointer checks and to let signed integers overflow.

Haskell also has different dialects, but in addition to compiler flags, you can also specify which variant of the language you are using via pragmas at the top of your file. In most cases, you can mix and match modules written in different dialects; because they get translated to a more stable intermediate representation before they are combined.

C doesn't have that luxury with its include files.

For C++, there's a long running proposal to add modules to the language. But from all I've read, thanks to all the other complicated features in the language, modules are unlikely to work well for C++. (I'm mostly basing that on https://vector-of-bool.github.io/2019/01/27/modules-doa.html )

Enough ranting. Summary: I agree that the standard authors make the best effort given the situation. Doesn't make the languages more sensible, though.

Making syntax errors UB instead of specifying that the program must refuse to compile may seem unfortunate, but it does have some justification: it allows implementations to add extensions to the language and still claim compliance with the standard. If the standard mandated that any syntax not allowed by the standard must cause a compilation error, any compiler adding extensions to C syntax would be in breach of the standard.

I don't see any problem with syntax not allowed by the standard being a breach of the standard.

And you don't see any problem with extensions being prohibited?

No, I don't. I think that extensions are extensions which by definition are not part of the standard.

Compilers should allow extensions, but the standard does not necessarily have to. I do not say it should be done this way, but it is perfectly possible to define a strict standard and leave extensions out of it.

That makes sense.

And that's what's happening in practice for some features.

GCC has a ton of options, and only a few of the myriad combinations give you a compiler that behaves strictly according to one of the C standards. And that's just fine.

In fact, compiler vendors experimenting, even in ways that are not allowed by the standard, is one of the main avenues to come up with new ideas for how to evolve the standard.

In fact, minor variations on semantics that are not allowed under the standard are probably more in spirit with C, than eg feeding the whole source file to a Python interpreter, if there's any string literal anywhere in the file that's not closed on the same line.

The former violates the standard, the latter complies.

The standard could mark that behaviour as implementation defined instead of undefined.

But it's really a non-issue: compilers like GCC don't claim to be standards compliant in all modes and with any combination of options. They are happy enough to have some combination of command line options that make them behave according to a specified standard.

The only sense in which an unterminated string literal can be UB is like this.

It's possible that if a string literal is not terminated, the situation will cause a de facto overly long string literal token to exist. For instance:

   const char *str = "short str; int x = 42; and now a realy long line follows ...

if the non-termination causes a de facto large literal to exist in the program, and that large literal exceeds a minimum implementation limit, then that is UB. Probably.

Strictly speaking, since the token is not closed, it is not a string literal, and so any limitation on string literals doesn't apply to it. Unless we interpret that limit as pertaining to the implementation's tokenizer, as such, which can plausibly choke on simply the valid prefix of a string literal that is too long.

Anyway, if a newline occurs before the minimum limit on string literal length is reached, and that newline is not escaped with a backslash, then that is a straightforward syntax error.

The standard could have still made that situation a syntax error, or at least implementation defined behaviour.

maybe you're thinking of unrecognized escape sequences?

E.g., printf("Hello \m") is undefined.

I wasn't thinking of those, but they would be good examples as well.

They could be declared implementation defined behaviour without sacrificing any flexibility.

Yep. The author's mis-statement:

> In C89, undefined behavior is interpreted as, “The C standard doesn’t have requirements for the behavior, so you must define what the behavior is in your implementation, and there are a few permissible options”.

Wrong. The entire point of "undefined" was to mean "the standard imposes literally no requirement."

"Implementation-defined" and "unspecified" are essentially what the author is thinking "undefined" means. To quote the standard:

> 3.4.1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made

> EXAMPLE: propagation of the high-order bit when a signed integer is shifted right.

> 3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

> EXAMPLE: the behavior on integer overflow.

> 3.4.4 unspecified behavior use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

> EXAMPLE: the order in which the arguments to a function are evaluated.

The author claims that, recently, the ocean has been getting concerningly wet. GCC 1.17 dates back to 1988 and would launch nethack as an easter egg in response to something as tame as implementation defined behavior (#pragma use.)

This is incorporated into a gamedev variation on "nasal demons" I've heard/parroted: "It can launch Nethack, it can launch nuclear missiles at a cow ranch in Alaska, or worse - it can do exactly what you expected it to do." The first two being perfectly standards-compliant behaviors when your code has an RCE vulnerability thanks to invoking undefined behavior via, say, buffer overflow. The last turning compiler upgrades into a minefield, and bug trackers into a dumping ground for once-encountered heisenbugs.

As a metapoint, the fact that there is this confusing epistemological minefield around the specified semantics is a bad thing in itself, separate from the evils of UB.

The implementation of stdlib necessarily contains code which invokes implementation defined behavior, and the reason that the compiler implementation doesn't treat it in like manner is simply that it doesn't identify it as such or is prevented from doing so. So the treatment of libraries doesn't need to be consistent with that of user programs. Practices that ensure that such code is not optimized away include scattering the information needed to do so across multiple translation units, so that the compiler does not put them together.

You're not wrong but what are the alternatives?

(1) Have a vague spec that doesn't distinguish between defined and undefined behavior.

(2) Define everything, at the cost of performance/hardware support.

Remember that C works on 50-year-old hardware, and current hardware.

(2) is the usual standard in computing. It's not like there aren't any performance or hw support compromises in current C.

I've become convinced that the original ANSI committee didn't intend to create the monster they did. The reason is that Dennis Ritchie wrote a submission to the committee¹ that 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”, and, that “[i]t negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) ‘the spirit of C.’”

Those comments describe what ‘undefined behaviour’ turned in to. The only reason dmr and others didn't make the same objections to it is that nobody realized at the time what the committee wording implied.

¹ available here: https://www.lysator.liu.se/c/dmr-on-noalias.html

I don't buy these arguments. Suppose you have a little bit of UB:

    char foo[10];
    foo[10] = x;

That's a buffer overflow, and a clever attacker can supply input for which this really will format your hard drive. Writing a standard that allows literally anything for this particular example of UB but somehow requires sensible behavior for other types of UB is not obviously possible. Merely saying that it can't happen doesn't make it so.

I believe the committee's intent was, as they stated, to ‘codify existing practice’. That means that the compiler generates code for the statement as written (in this case, a store into location foo+10) and what happens when it runs is up to the machine and not the compiler's problem.

At the time ANSI C was under way, I was working on a commercial C compiler and following developments closely. I don't think anyone anticipated what ‘undefined behavior’ would turn into.

The problem with that approach is it inhibits a lot of perfectly-sensible optimizations. If you force the compiler to leave it up to the machine, you force it to preserve the same stack layout, the same memory write, and the same execution order relative to everything else.

You basically forbid it from working with an execution model at any level higher than "a giant array of bytes," because now you have to preserve the naive behavior of that giant array of bytes. But this is not really useful for correct programs.

The committee's intent may have (accidentally, indirectly) been to codify compilers that do very little optimization, but that doesn't mean it was a good idea.

Thanks for the link!

Yeah, though that's largely irrelevant to the point of this document.

Regardless of the cause (if it's that "one word" or not), the behaviors are crazy-making and there's a trend of more aggressively exploiting UB for optimizations.

Honest question, since I have no expertise in the field: If C89 says that "Permissible undefined behavior" includes "ignoring the situation completely with unpredictable results" can you give an example of something that would constitute non permissible undefined behaviour according to the standard?

The author's interpretation is completely spot on. C89 does not allow the implementation to deliberately break a program that invokes undefined behavior, unless they document what they are doing. It may allow the program to break due to ignoring the situation.

> There is absolutely no requirement to document what those "unpredictable results" might be.

Only in that case: when the situation has been ignored completely.

If the situation has not been ignored completely (for instance, the compiler analyzes for the absence of that type of undefined behavior and optimized based on that), then it is not permissible to behave with unpredictable results. The behavior now falls into a "documented manner characteristic of the implementation", or else terminating at translation or execution time with or without the issuance of a diagnostic.

One way to look at this is that they changed "permissible" to "possible" for a reason. What might that reason be? Almost certainly that the word "permissible" gives requirements.

> If the situation has not been ignored completely (for instance, the compiler analyzes for the absence of that type of undefined behavior and optimized based on that)

Except optimizing based on undefined behavior is also a form of ignoring the situation. For example, say you have code that can:

1. Execute Action A if undefined behavior is present, or

2. Execute Action B if undefined behavior is not present.

A compiler could look at these two possibilities, see that one of them invokes undefined behavior, ignore that situation completely, and optimize the remaining path. And that would be perfectly in line with the wording of the standard.

The interpretation you and other commentors who dislike optimizations based on UB favor is that "ignoring the situation" should mean "treat the code as if it was conforming". Both are valid readings of the standard, and the only way one will become the dominant reading would be for the standard to use less ambiguous wording.

> Except optimizing based on undefined behavior is also a form of ignoring the situation.

That is illogical.

1. The optimizing is based on undefined behavior (your exact words). (Actually it is based on the assumption of freedom from a specific undefined behavior, but the assumption is somehow tied to that case of undefined behavior.)

2. The situation that is to be "ignored completely" is the undefined behavior.

3. So the "based on" and "ignore completely" both refer to the undefined behavior.

4. Contradiction: "based on" is quite opposite to "ignoring completely". You can only be doing one or the other.

Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning.

I don't think that the original ANSI C committee would have signed off on that change. It's not an interpretation of existing committee intent, but a case of new people changing the language.

The purpose of, say, numeric overflow being undefined is that implementations didn't agree on how it was handled. Compilers simply passed that on to the machine code. that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation. Programmers who understand the machine could infer the behavior anyway, for their platform.

> see that one of them invokes undefined behavior, ignore that situation completely

Removing something from consideration after evaluating it is not compatible with the wording "ignore completely". It might be compatible with "ignore"; I could swallow that much. Definitely with the "completely" though. The C89 authors added that adverb there for a reason.

> And that would be perfectly in line with the wording of the standard.

Well, with the current wording, not the historic wording in C89.

> That is illogical.

It's illogical because of poor wording on my part that didn't really match what I wanted to say, yes. Sorry about that. As you noted, a better phrasing might be "Optimizations based on ignoring executions that result in undefined behavior is also a form of ignoring the situation". Hopefully that better captures my intent.

> Also, you're neglecting to provide a plausible hypothesis as to why "permissible" had to be changed to "possible", if it makes no difference in meaning.

I didn't intend to explain that change in wording because in my opinion it doesn't make a difference as long as the "ignoring the situation" clause remains.

> that's what it means to "ignore the situation completely": just compile the code, and let whatever happen in the translation.

That's one interpretation. The other is to ignore the code that invokes undefined behavior and optimize as if it was not there.

> Removing something from consideration after evaluating it is not compatible with the wording "ignore completely".

I'm not sure I would necessarily agree that "completely" would preclude evaluating the situation at all, but my command of English is lacking.

I think it actually wouldn't matter; given some code that may or may not exhibit UB, there are arguably two ways to end up with only one case to consider:

1. Ignore the code that exhibits UB

2. Ignore the UB and treat the code as conforming

Evaluation of the options will have to take place either way, whether it is at compiler run time, compiler design/write time, both, or something else.

I think the only fact that rescues this situation is that in the same paragraph, there is wording which assures the implementor that UB "imposes no requirements" (famous fact everyone basically knows). The later "permissible" is an unfortunate word that appears to give requirements. Without the "imposes no requirements" to contradict that word, it would be a lot more troublesome.

I wrote a detailed reponse to the blogger, which is "awaiting moderation". I not only point out that the C89 wording is contradictory, which justifies the replacement of the word, but that all sorts of common, useful optimizations are predicated on the absence of the program's reliance on undefined behavior.

If we cannot optimize based on the absence of undefined behavior, we cannot cache variables in registers or do CSE, or only in a lot fewer possible cases.

At best we can do back-end things that just improve the compiler's output without regard for the original program (optimal allocation of real registers to pseudo-registers, peephole optimization, jump threading, ...)

If your comment never makes it out of moderation limbo (or maybe even if it does), would you mind posting it here?

How does not being able to assume the absence of UB prevent optimizations like those you listed? Not that I'm doubting you; this is an area I'm not very familiar with.

On the other hand, this is arguably just a simple defect in the C89 wording.

In the previous sentence, it is clearly written "... for which the Standard imposes no requirements."

The issue is then that "permissible" appears to give requirements.

That's an apparent contradiction in wording, which they rectified by changing "permissible" to "possible", which is a justifiable action that doesn't change the language.

"Ignoring the situation" is not the same as do whatever you want.

And "do whatever you want" isn't really what compilers are doing either. Out of all possible program executions, they are ignoring the situations where undefined behavior is invoked. That (arguably) matches what the standard says, does it not?

Take the example with writing to NULL. Ignoring the situation means writing to NULL anyway or not writing to the address, not removing the if statement. Making assumptions about the value of a pointer based on UB is not ignoring the situation, that's trying to take advantage of the situation.

> Making assumptions about the value of a pointer based on UB is not ignoring the situation

But it is? Out of all situations, you ignore those that invoke UB. It's technically correct, but can produce bad results. What you want is to ignore the undefined behavior itself, and to treat the code as conforming. That's an equally valid interpretation, and the only way to definitively get one interpretation over the other is for the standard to change that wording to say so.

> The only way to definitively get one interpretation over the other is for the standard to change that wording to say so.

No. If the interpretation of the standard results in a behavior that makes the result obviously worse, nobody should favor such an interpretation.

Even if the behavior is "undefined" as per standard, that doesn't mean that any compiler should "define" its own interpretation and implementation in a way to make every resulting program worse.

They obviously "can" and obviously are already doing this, but even that doesn't make such an approach good or desired by any user of that compiler.

> If the interpretation of the standard results in a behavior that makes the result obviously worse, nobody should favor such an interpretation.

This would be true if everyone actually agreed that the more aggressive interpretation is obviously worse. Since said interpretation is claimed to result in better performance, though, it's not very clear-cut.

That's the nature of ambiguity; either you rely on convention to establish a canonical behavior, which doesn't appear to be likely to happen any time soon and isn't guaranteed to remain the same over time, or you change the wording to no longer be ambiguous.

> to make every resulting program worse.

That's the crux of the issue though, isn't it. I'd like to think that the compiler developers are not programming at random, and that the optimisations do improve the compilation of code that only uses defined behaviour.

If the only defined value for a condition is effectively:

    if (false) { ... }

surely removing the branch is the best thing to do, regardless of what is inside the braces?

If a language makes it easy to accidentally write if (false) when the programmer was trying to test some real condition, then surely that's a problem with the language, not the compiler.

But it's not "if (false)" that was originally written. It's the problem only when the language lawyers search for the "loopholes in the standard" to derive the meaning that is turning

   if (make sure something bad is not going on) {
       do_something
   }

to the following:

"I clever compiler author devised a way to analyze do_something and I see that you the writer of the code managed to write do_something in a way that can be considered "undefined behavior" according to this standard I'm using, therefore I am "allowed" to also remove the "if (make sure something bad is not going on)" to... nothing! See how fast the resulting code now is!"

It's searching for the loopholes to do something directly against the intention of the writer of the code that people have problems with.

In that light I fully agree with Linus:

https://lkml.org/lkml/2018/6/5/769

"I've said this before, and I'll say it again: a standards paper is just so much toilet paper when it conflicts with reality. It has absolutely _zero_ relevance."

"There are competent people on standards bodies. But they aren't _always_ competent, and the translation of intent to English isn't always perfect either. So standards are not some kind of holy book that has to be revered. Standards too need to be questioned."

I'm glad my compiler searches for those situations and removes the unneeded if. I write a lot of generic code - often I need the if only in some situations and write it trusting the compiler will figure out the situations I don't need it and remove the if. Without this I'd have to spend a lot of effort maintaining hundreds of almost the same copies of my code different only where there is a might or might not be needed if. Not to mention all the likely bugs when someone doesn't select the right version of my code to use.

In the given example, the if check for null was NOT unneeded at all, it was vital for proper program operation. Optimizing it away caused a bug that should not have occurred.

That happens once in a while when you try to exploit undefined behavior. I don't do that in my code. I use undefined behavior sanitizer to prove that statement (without that tool I make mistakes)

But it's not the programmer trying to exploit undefined behavior, it's the compiler. That's just wrong. How would you check for a null pointer in a way that the compiler can't optimize away?

Like this:

  if (ptr) *ptr = 2;

I sort-of agree with you that 'exploiting' undefined behaviour is a bad thing. But that's what C (and C++) are all about: the undefined behaviour everywhere allows the compiler to make lots of optimizations without having laboriously to prove that they are safe. And those languages are all about speed at the expense of safety.

If you want (more) safety, there are languages for that. Including C dialects you get via various compiler flags. Eg the Linux kernel uses a special gcc compiler flag to keep all null checks. For this very reason.

See https://people.csail.mit.edu/nickolai/papers/wang-undef-2012... for an overview with examples from the kernel, and lots of cases where the kernel authors opted for a compiler flag to effectively use a more defined dialect of C.

> Even if the behavior is "undefined" as per standard, that doesn't mean that any compiler should "define" its own interpretation and implementation in a way to make every resulting program worse.

The standard offers no interpretation of any undefined behavior, that's literally what meant by undefined. There is no execution of a program that contains UB that could be considered 'valid' by the standard. The compiler has no choice, it has to define its own interpretation.

To make matters worse, undefined behaviour doesn't just exist at runtime. It can also happen at compile time etc. And it is allowed to time travel.

> The standard offers no interpretation of any undefined behavior

"The standard" is not compiling my program, the real compiler is doing that, and the authors of that specific implementation should do the right thing, in spite of the standard leaving something "undefined."

> The compiler has no choice, it has to define its own interpretation.

Correct. And it can define it as to not to be an adversary to the writer of the code.

What is the “right” thing to do with UB, and who defines what is right, if not the standard? You?

> What is the “right” thing to do with UB

It is actually quite clear in most of specific cases, as Linus pointed even 18 years ago:

https://gcc.gnu.org/legacy-ml/gcc/2002-01/msg00418.html

"When it comes to optimization, there are things that are "obvious", and that will never generate any discussion at all, because they are faster ways of getting the exact same result, with no question about it. Nobody will ever fault a compiler for evaluating constant expressions at compile-time rather than doing the math at run-time and getting the same result. The two are indistinguishable from a result standpoint.

But optimizations that can change the value of an expression are slightly different. They should make sense. You should be able to _explain_ them."

"If you cannot explain the results, you end up having to argue about word-weaseling in the standard, and people _will_ disagree on what the damn thing means. Because standards aren't mathematically exact things."

> it can define it as to not to be an adversary to the writer of the code.

We see peculiar things happen when there's undefined behaviour, because of the way compilers' optimisers work. It would be possible to tame the way undefined behaviour manifests, but this would trade off against the compiler's ability to optimise. If that weren't the case, everyone would be doing it.

The unsigned short to signed int promotion is an example of "compiler-manufactured" UB. The compiler could have chosen a type promotion that does not cause UB.

I believe compilers are constrained by a combination of ABI and the standard here. Section 6.3.1.1 of the C11 draft states [0]:

> If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

So the type that the compiler promotes to is determined entirely by the widths of unsigned short and signed int, which in turn are defined by the ABI. There is no room for picking a different promotion here.

[0]: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf

> The standard offers no interpretation of any undefined behavior, that's literally what meant by undefined

Correct.

> There is no execution of a program that contains UB that could be considered 'valid' by the standard.

That strikes me as backward. It would be more correct to say There is no execution of a program that contains UB that could be considered 'invalid' by the standard.

Even this isn't quite precise enough though. If there's undefined behaviour in a function which is never used, that doesn't cause the program to have undefined behaviour.

> The compiler has no choice, it has to define its own interpretation.

No, it doesn't. That's only true of implementation-defined behaviour. In the case of undefined behaviour, the program doesn't even have to behave the same way every time.

https://en.wikipedia.org/wiki/Unspecified_behavior#Implement...

What does 'removing a statement' even mean?

C statements aren't translated one-for-one to machine code, so you can't just talk about 'removing a statement'.

In any case, lots of undefined behaviour is in the standard exactly so that the compiler can take advantage of the situation.

That's mostly so that the optimizer's job is simpler.

Eg the compiler can assume that you are checking for null yourself already, so reasoning-by-contradiction it can assume that when an execution path looks like it might access a null pointer, that it means this path is dead code. (And there's lots of dead code around.)

Similarly, the compiler is allowed to assume that loops that have no side-effects terminate. (Or rather, non-terminating loops without side-effects are undefined behaviour. So you can't rely on them to implement a busy wait.) See "C Compilers Disprove Fermat’s Last Theorem" https://blog.regehr.org/archives/140 for more about this.

The whole point of the null pointer example is that "you are checking for null yourself" doesn't work in that situation, because the compiler optimizes out the check. It becomes impossible to do the right thing.

No, the compiler doesn't optimize out proper null-checks.

Eg the compiler leaves this one in:

  if(ptr) *ptr = 2;

But if you do something like this:

  int* next = ptr + 1;
  if(ptr) {
    *ptr = 2;
    ptr = next;
  }

Then the compiler 'knows' that you must have already checked the ptr for null, and can elide the redundant check.

So what you're saying is that this is guaranteed to work:

    if(ptr) ptr->action1();
    if(ptr) ptr->action2();

While this might blow up:

    if(ptr) {
      ptr->action1();
      ptr->action2();
    }

That's the only if statement in all of C that works that way, and violates the principle of least surprise in a huge way.

LOL... just crash the app, and then document that it's supposed to make demons fly out of your nose and that it only works with blood sacrifice hardware installed.

"Demon summoning failed, nasal hardware not found."

You are looking for a version of C that traps on undefined behavior–which is totally fine!–but do know that this would either be something that does not optimize code and/or contains runtime security checks for things that C traditionally does not have checks for.

Trapping implementations have a long and honourable history on platforms where the hardware supports it. Ironically, the whole reason most undefined behaviour is undefined is to permit trapping implementations - implementations that do something safer than just continuing with an implementation-defined value - but instead modern compilers treat it as a license to do something even more dangerous.

Thankfully, modern compilers have begun inserting traps much more often upon running into undefined behavior.

yes of course, you would need a well grounded summoning grid.

Reply on news.ycombinator.com