Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods programmers believe about undefined behavior

predr.ag

Post reply on HN
Print view View original

181–190 of 233 posts

Re: Falsehoods programmers believe about undefined behavior

#181

Post by nayuki »

account42 wrote: post #140
AstralStorm wrote: post #120

Earlier quoted context omitted.

UB can easily wipe "the drive" on my microcontroller by sending a wrong SPI command to the flash chip, or by messing with write unprotected memory mapped built in flash. Welcome to kernel code. I believe one could make it play DOOM by clever malice in this case.

We need a doomcc that will replace all undefined behavior with doom. A more fun version of ubsan if you will.

Thanks for inadvertently realizing my prediction.

> When a C or C++ program triggers undefined behavior, anything is allowed to happen in the program execution. And by anything, I really mean anything: The program can crash with an error message, it can silently corrupt data, it can morph into a colorful video game, or it can even give the right result.

-- https://www.nayuki.io/page/undefined-behavior-in-c-and-cplus...

Re: Falsehoods programmers believe about undefined behavior

#182

Post by Mathnerd314 »

obi1kenobi wrote: post #126
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…

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into why: https://www.youtube.com/watch?v=yG1OZ69H_-o (I'm the post's author.)

"goes into". https://youtu.be/yG1OZ69H_-o?t=1039 You mean this slide of the Joker with title "Do I really look like the kind of language that would define its behavior?"

As far as I can tell there is no reason LLVM couldn't compile a document like "On x86 division by zero throws a #DE exception. On ARM division by zero returns zero. On x86 shifting by more than 32 bits shifts by (cnt mod 32) bits. On ARM shifting by more than 32 bits clears all bits. [...]" that specifies all undefined behavior. The current "nasal demons" behavior is preferred in the name of performance on some SPEC benchmarks that nobody was asking for, screwing OS writers and anyone who expected sane language semantics.

Re: Falsehoods programmers believe about undefined behavior

#183

Post by layer8 »

The way to think about UB is that it’s like a false premise. Anything and everything can be derived from a false premise. Compilers can end up with arbitrarily false conclusions if the program contains a false premise.

The other important thing to realize is that UB is generally a runtime condition and cannot be detected statically, in the general case. That’s usually why it’s been made UB in the first place.

Re: Falsehoods programmers believe about undefined behavior

#184

Post by nayuki »

olliej wrote: post #153
anonymoushn wrote: post #82

Earlier quoted context omitted.

I think memcpy is fine because it operates on a special type that is allowed to alias anything. Strict aliasing has other fun issues like the impossibility of implementing malloc-like functions or the lack of any requirement for access to non-char members of structs to work at all[0]. [0]: https://stackoverflow.com/questions/49298704/how-reason-abou...

memcpy is UB because it reads padding bytes in structs. memmove fails as it requires pointer comparisons between separate allocations, which is UB.

memcpy() and memmove() are language-level functions. They are allowed to do things that cannot be implemented in user code. The C standard library's implementation of these functions have tight integration with the compiler to ensure that it can implement all the required semantics without triggering undefined behavior.

Re: Falsehoods programmers believe about undefined behavior

#185

Post by Kranar »

torstenvl wrote: post #40
gpderetta wrote: post #24

Earlier quoted context omitted.

> there are better and worse things compilers can do in the presence of UB, and the big one is warning you about it when it possibly can. GCC should add -Wundefined-behaviour flag that will unconditionally print "warning: this program might or not have UB" as the first diagnostic.

It should also warn if there are infinite loops, so the dev can know whether it will ever halt.

Infinite loops are undefined behavior in C++.

Re: Falsehoods programmers believe about undefined behavior

#186

Post by marmetio »

gpderetta wrote: post #179
marmetio wrote: post #178

Earlier quoted context omitted.

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.

I know what you're referencing, but it's not obvious to people who don't already know about it.

And in a way, I think you did say something deep. Web developers often have no idea that problems like this were solved a long time ago, and it lowers their expectations for what should be possible with the tools of their industry.

Re: Falsehoods programmers believe about undefined behavior

#187

Post by Karellen »

obi1kenobi wrote: post #172
csours wrote: post #150

Earlier quoted context omitted.

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 :)

I did get that eventually, but I missed the side-note in my first read through, and it was lumping two concepts together under the name of one of them that I found confusing.

If, in your description of the three buckets, you called the middle one something else like "Platform-dependent behaviour" or whatever, I think that would have been less weird. You'd still only need one short paragraph to say it's compiler/OS/hardware dependent, covers implementation-defined and unspecified, and is not the focus of the article.

Re: Falsehoods programmers believe about undefined behavior

#188

Post by matkoniecz »

bmacho wrote: post #115
matkoniecz wrote: post #14

Earlier quoted context omitted.

> Does this include that a compiler, when it can prove that a program it compiles contains UB, erase your disk as part of the compilation process? i.e. without you ever running the compiled program. No, but technically compiler would not violate specification by compiling program that on running will scan your disk for secret data, publish it online, apply ransomware to your disk and deliberately destroy your SSD.

What about the C programs? I guess the program void main(){}; is allowed to row hammer your RAM and inspect and modify the states of other programs, but is it allowed e.g. to delete your file system through a system call?

Is it program with UB?

If yes, then compiler can compile program doing literally anything* and be in compliance with standards as defined.

*including hacking Pentagon to order drone strike on location where it was compiled.

Or summoning demons.

Or deleting your file system through a system call.

Re: Falsehoods programmers believe about undefined behavior

#189

Post by quelsolaar »

This post is very good. One thing to add, is that if you code has not entered a state of UB yet, but will at some point, then all bets are off. The phenomenon is generally known as time traveling UB.

Compilers assume your code doesnt contain UB. Example:

If(x == 0) printf(“hello”); y /= x;

The compiler can assume x is not zero because it assumes the user will not cause UB, therfore the if statement and printf can be removed.

Re: Falsehoods programmers believe about undefined behavior

#190

Post by [deleted] »

matkoniecz wrote: post #188
bmacho wrote: post #115

Earlier quoted context omitted.

What about the C programs? I guess the program void main(){}; is allowed to row hammer your RAM and inspect and modify the states of other programs, but is it allowed e.g. to delete your file system through a system call?

Is it program with UB? If yes, then compiler can compile program doing literally anything* and be in compliance with standards as defined. *including hacking Pentagon to order drone strike on location where it was compiled. Or summoning demons. Or deleting your file system through a system call.

[deleted]
Post reply on HN