Falsehoods programmers believe about undefined behavior • Hacker News Board

Re: Falsehoods programmers believe about undefined behavior

#171

Post by Quekid5 » Mon, Nov 28, 2022, 5:32 PM UTC

scoutt wrote: post #162

mattarm wrote: post #158

Earlier quoted context omitted.

An automobile recall is a good analogy here. Most people driving cars with an active recall are unaffected by the problem the recall is supposed to address. They can drive on blissfully unaware that something could go wrong. They might even enthusiastically recommend that others purchase the car they drive. For a few people, they'll experience a failure, possibly a dangerous one. And this is the root of the problem.…

The same applies to vaccines and medicine drugs. Should we stop giving them to people? "For a few people, they'll experience a failure, possibly a dangerous one.". Should we try our best to minimize the risks? Absolutely. But we are talking programs here. We shouldn't measure every program with the same ruler. Not all programs need to be MISRA compliant when they don't need to. My Reddit app crashes several times a d…

There are no viable alternatives to vaccines and medicine in general (ones that actually work, that is). There are alternatives to C -- for most cases.

> My Reddit app crashes several times a day, and I guess there is no immediate danger.

That's because your app is heavily sandboxed and probably (on Android, at least) running in a VM which enforces memory safety and isolation from other apps.

If each crash had, say, a 1% likelihood of eating a large portion of your data (or leaking pictures or whatever) you'd probably care a lot more about it.

The problem highlighted by the parent poster is that all these little risks add up and often end up being catastrophic (e.g. heartbleed) because so much of what we run is interconnected via the network (or just data in files).

Re: Falsehoods programmers believe about undefined behavior

#172

Post by obi1kenobi » Mon, Nov 28, 2022, 5:35 PM UTC

csours wrote: post #150

Karellen wrote: post #85

It does seem odd to just "lump unspecified behavior and implementation-defined behavior together" in a side-note under the heading of "implementation-defined behaviour", when that term has a precise technical meaning in the C and C++ specifications.

I think that note just means "this post isn't about unspecified or implementation defined behavior". I'm sure you could write articles about each of those.

Post author here, and yes this ^ is precisely what it's intended to mean. There are also other more exotic flavors of behavior, and the post isn't about those either.

I tried to cover as much ground in the post as possible, but the post is already a 10min read and covering unspecified / impl-defined behavior would have made it a 20min read instead :)

Re: Falsehoods programmers believe about undefined behavior

#173

Post by Psyladine » Mon, Nov 28, 2022, 5:39 PM UTC

mnw21cam wrote: post #107

I have a suggestion - it may be completely off the wall, but hear me out. C needs a mechanism to declare in a source file that certain behaviour must be defined, where that behaviour is undefined in the C standard but the target architecture behaves the defined way. Then, when the source is compiled on the target architecture it works as expected, but when compiled on something else it refuses to compile. For example…

If the program knew the intention of the programming we wouldn't need programmers to begin with. Undefined behavior may be obvious to the architect but not to the architecture.

Re: Falsehoods programmers believe about undefined behavior

#174

Post by obi1kenobi » Mon, Nov 28, 2022, 5:41 PM UTC

koala_man wrote: post #149

My least favorite thing about "falsehoods X believe about Y" articles is that they make a point out of not backing up or demonstrating any of their claims.

Fortunately, this post includes a link to an excellent 45min talk on undefined behavior which does go into a fair bit of the detail you were looking for. I encourage you to click it -- it's right in the post's introduction.

The purpose of this post and other "falsehoods" posts is to shine a light on the existence of a misconception or set of misconceptions. By that point, there are usually plenty of other high-quality posts about "why / how / when" etc. but for a variety of social dynamics reasons those posts by themselves did not have the wide distribution and readership they deserved. After shining a light on the misconception, interested readers are generally able to continue the learning process both through the sparked discussion and through doing their own searching.

Here's a specific example of such a post with even more details: https://blog.llvm.org/2011/05/what-every-c-programmer-should...

Re: Falsehoods programmers believe about undefined behavior

#175

Post by AstralStorm » Mon, Nov 28, 2022, 5:43 PM UTC

haberman wrote: post #139

AstralStorm wrote: post #128

Earlier quoted context omitted.

That is not an infinite loop, it has an exit condition on i > n. An infinite loop is not UB. It is well defined. Just the definition of a terminating loop is a bit funny. > An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression,…

> An infinite loop is not UB. It is well defined. From C11: > An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate.15…

Not particularly. It does not allow the compiler to assume true infinite loops can terminate.

It only allows the compiler to assume loops with non-constant expressions can terminate. (And a bunch of other exceptions where it cannot.) A true infinite loop has a constant expression as the conditional and cannot be optimized away based on this rule.

What this rule allows the compiler to do is to optimize away loops where number of iterations are known ahead of time if it has a non-constant expression condition.

Re: Falsehoods programmers believe about undefined behavior

#176

Post by MushyQuadrant » Mon, Nov 28, 2022, 5:45 PM UTC

yccs27 wrote: post #87

leni536 wrote: post #22

13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…

Can someone with more knowledge chip in? If I define void bar(int* const p, int n) { for (int i=0; i it might get optimized via loop-invariant code motion to void bar(int* const p, int n) { int m = *p for (int i=0; i so it could still be UB when called with p=NULL and n=0, right? Edit: Oops, in the previous version I used a write instead of a read on *p, making the optimization invalid.

The first form has no undefined behavior. Since p may be NULL, in general the compiler is not allowed to make that transformation unless it can prove bar never gets called with p=NULL and n=0 (which it probably can't).

If the compiler has some special knowledge of the target architecture which makes the second form behave as if the first form was executed (such as if NULL is a valid address on the target architecture), it may make the transformation, but that still wouldn't cause undefined behavior, because it must behave as if it had the first form.

Re: Falsehoods programmers believe about undefined behavior

#177

Post by obi1kenobi » Mon, Nov 28, 2022, 5:46 PM UTC

sokoloff wrote: post #28

victor82 wrote: post #16

It is not explained why points 31 to 36 are valid, unlike HDL synthesis tools, C compilers are pretty deterministic, same input same output, except timestamps, etc. If an UB adopt X behavior one time, a reproducible build will take same X behavior the next time. Of course I am not negating the fact that this undefined in the first instance nor condoning the UB usage.

That is the observed behavior of the compiler not the defined behavior. (and while there’s some logical reason to assume that will likely continue to hold, the list is falsehoods programmers believe about undefined behavior, not observed behavior.)

(Post author here.) Agreed with the parent comment. To restate the same thing in another way in the hope of avoiding confusion:

It isn't a bug in the compiler if the compiler is non-deterministic in the presence of UB. Such behavior does not violate any guarantee provided by the compiler or language spec.

In fact, it's still not a bug if the compiler is non-deterministic, full stop. Many (most?) compilers have non-deterministic behavior due to a variety of factors. To get a sense of what's involved in getting determinism, look up some articles on why it's difficult to get reproducible builds working. It's a lot harder than it might seem at first.

Re: Falsehoods programmers believe about undefined behavior

#178

Post by marmetio » Mon, Nov 28, 2022, 5:58 PM UTC

gpderetta wrote: post #167

marmetio wrote: post #145

Earlier quoted context omitted.

Ada already does something like this. You can choose whether to enable runtime checks, fail to compile, or accept the risk. The purpose of C is to be easy to implement on new systems. You're never going to get a lot of traction adding anything to C proper.

> Ada already does something like this. You can choose whether to enable runtime checks, fail to compile, or accept the risk. It is ok, the accelerometer readings won't go outside the range of an int.

I think it's silly to tell people what to do when you don't know what they're doing. For all you know, they could be generating code from a design tool that already does that static analysis.

What's nice about Ada is you have choices, and the ecosystem facilitates creating and using such tooling.

Re: Falsehoods programmers believe about undefined behavior

#179

Post by gpderetta » Mon, Nov 28, 2022, 6:02 PM UTC

marmetio wrote: post #178

gpderetta wrote: post #167

Earlier quoted context omitted.

> Ada already does something like this. You can choose whether to enable runtime checks, fail to compile, or accept the risk. It is ok, the accelerometer readings won't go outside the range of an int.

I think it's silly to tell people what to do when you don't know what they're doing. For all you know, they could be generating code from a design tool that already does that static analysis. What's nice about Ada is you have choices, and the ecosystem facilitates creating and using such tooling.

I wasn't trying to say anything deep. It was just a reference to the Arianne 5 disaster.

Re: Falsehoods programmers believe about undefined behavior

#180

Post by nayuki » Mon, Nov 28, 2022, 6:10 PM UTC

nmilo wrote: post #113

I thought this was going to be an actually useful post about the details of UB, when it happens, and what it generally looks like, but instead it's just more of the same often repeated "if you write a program with UB your compiler will literally summon dragons and wipe your hard drive and kill you in your sleep." The truth is that practice diverges from theory, and, in practice, it is actually useful to talk about UB…

>> Falsehood #28. At least it won't completely wipe the drive.

> This is just unhelpful for anyone trying to learn more about UB. [...] And if you literally write "rm -rf /" in these dead sections, then yeah, I guess UB is technically wiping your drive, but stating it like that just gets in the way of anyone trying to learn more about UB and just perpetrates this unhelpful theory that UB can literally do anything it wants

The example is contrived, yes. But even if the source code doesn't literally contain "rm -rf /", if the program contains a buffer overflow vulnerability, then someone can craft an input to inject arbitrary code/commands into the program execution and still effect a deletion anyway. So yes, UB really does mean anything can happen.