{"id":48205980,"user":"saagarjha","time":1779276056,"time_ago":"5 months ago","type":"comment","content":"

But be as you may you’re not following the standard.","comments":[{"id":48206569,"user":"jstimpfle","time":1779279855,"time_ago":"5 months ago","type":"comment","content":"

what is your point?","comments":[{"id":48206706,"user":"Xirdus","time":1779280653,"time_ago":"5 months ago","type":"comment","content":"

If you don't follow the standard, gcc -O2 can introduce bugs to your code that you never even wrote. Skipping null checks, executing both branches of a conditional, and so on.","comments":[{"id":48206724,"user":"jstimpfle","time":1779280786,"time_ago":"5 months ago","type":"comment","content":"

Where did I say I'm not following the standard?","comments":[{"id":48206945,"user":"Xirdus","time":1779281905,"time_ago":"5 months ago","type":"comment","content":"

I interpreted these words:

> If you want to be standards correct, yes you have to know the standard well.

to mean that being standards-correct is optional. It's not. Every C programmer needs to know every possible UB by heart and never introduce any of it to their code, or else they'll be constantly introducing subtle, hard to debug bugs that contradict the actual code they wrote.

Maybe you meant something different by those words, but then I'm confused what the "if" was supposed to mean.","comments":[{"id":48208035,"user":"jstimpfle","time":1779285969,"time_ago":"5 months ago","type":"comment","content":"

Of course it's optional (although I didn't mean to imply that). Even using computers at all is optional. I never said that I don't aim to follow the standard, have a clean compiling program without warnings and without UB, etc. I do strive to achieve all of that.

But it's not entirely black and white, either. In practice I'm fine accepting that some bugs are technically UB but whatever, we've found a bug by whatever manifestation (like NULL dereference most likely leading to segfault in practice). I just fix the bug as a bug, and life goes on.

The standard is not perfect, it does have shortcomings. It can be improved. And it can be interpreted to fix some issues. Let's not hold theory over practicality, and let's expect the compiler writers also strive to do the reasonable thing.","comments":[{"id":48214046,"user":"Xirdus","time":1779310669,"time_ago":"5 months ago","type":"comment","content":"

In practice, GCC -O2 will happily erase entire swathes of code and turn perfectly logical source into nonsense assembly whenever it gets as much as a sniff of UB anywhere in the code path. Nobody would be talking about UB if GCC wasn't so aggressive in abusing the freedom UB gives.

To paraphrase your earlier comment - you lose low-friction polymorphism (unpredictable compiler output causes a lot of friction). You lose control of memory allocations (because they may have been elided) and lose control of lifetimes (because free can be moved before last use causing a crash, or removed entirely causing a leak). You lose control of (almost) anything that happens in the system. And it has everything to do with not following the standard.

You do retain control of the memory layout of data structures, though.","comments":[{"id":48214950,"user":"jstimpfle","time":1779315211,"time_ago":"5 months ago","type":"comment","content":"

Then I'm almost ashamed to admit that I'm not sure I've ever witnessed any surprising form of UB in the wild. For example, I will reliably get segfaults on NULL dereference in practice. Typical manifestations of UB are entirely predictable and obvious. Of course I'm also running most code without most optimizations, most of the time, while developing.

On the other hand, what I've observed with my own eyes is interesting phenomenons like performance drops, e.g. memory bandwidth dropping from gigabytes/sec to 300 KB/sec due to false sharing on an ARM SOC for example.","comments":[{"id":48222108,"user":"Xirdus","time":1779369239,"time_ago":"5 months ago","type":"comment","content":"

There was once a privilege escalation vulnerability in Linux kernel that only happened when compiled with optimizations. In kernel space, address 0 is just regular memory that can be read from and written to if there's a page mapped to it. But in C standard, reads and writes to null pointer are UB.

There was some function that read from a passed pointer unconditionally whether it's null or not. It made sense in context. Then it checked if the pointer is null - if it is do early return, if it's not do privileged operation. The pointer was null iff the user didn't have permissions to do the operation.

What GCC did is notice that a pointer is accessed before its null check. Since accessing a null pointer is UB, and GCC assumes UB never happens, it figured out the null check is superfluous. And removed the check and the early return. The pointer read stayed, mind you. The optimized function would unconditionally read from the pointer even if it's null, then unconditionally execute the privileged operation without checking permissions. That allowed obtaining root access from anywhere.

I saw a few other writeups of interesting UB behavior on The Old New Thing blog. I especially like the time travel one: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63... (apologies to people of the future, links to MS devblogs tend to die often).","comments":[],"comments_count":0,"level":7,"url":"item?id=48222108"},{"id":48219131,"user":"saagarjha","time":1779348874,"time_ago":"5 months ago","type":"comment","content":"

Compilers do not surprise all that often which is why it is extra surprising when it does happen","comments":[],"comments_count":0,"level":7,"url":"item?id=48219131"}],"comments_count":2,"level":6,"url":"item?id=48214950"}],"comments_count":3,"level":5,"url":"item?id=48214046"}],"comments_count":4,"level":4,"url":"item?id=48208035"}],"comments_count":5,"level":3,"url":"item?id=48206945"}],"comments_count":6,"level":2,"url":"item?id=48206724"}],"comments_count":7,"level":1,"url":"item?id=48206706"}],"comments_count":8,"level":0,"url":"item?id=48206569"}],"comments_count":9,"url":"item?id=48205980"}

Comment by saagarjha