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

Everything in C is undefined behavior

blog.habets.se

Post reply on HN
Print view View original

481–490 of 748 posts

Re: Everything in C is undefined behavior

#481

Post by dwattttt »

shakna wrote: post #400
saagarjha wrote: post #389

Earlier quoted context omitted.

That they won’t is as most a courtesy to you but they are not required to do this.

> Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. I quoted the C standard, first. Not compiler behaviour. I showed where it requires the compiler not to optimise this. How about, instead of one-line throwaway disagreements, you point out where they are permitted to do this…

The compiler is required to not optimise out reads/writes through volatile. That's unrelated to code also having UB: you can't sprinkle volatile through arbitrary UB and suddenly have it be defined.

> A compliant compiler is only free to optimise away, where it can determine there are no side-effects

A compliant compiler is also allowed to assume UB cannot occur.

Re: Everything in C is undefined behavior

#482

Post by QuiEgo »

C does not abstract differences in underlying hardware well. Systems programmers know if they have an architecture that can't handle unaligned accesses or that the address they are doing load/stores from is a mmio register. Systems programmers know the difference between a virtual address and a physical address and have debugged MPU faults or MMU table walks and page faults more times than they want to think about.

C is horrible for trying to write a portable user-mode program in 2026. There are lots of better options.

C is great for writing low-level system code where you need to optimize performance down to the last cycle. It not abstracting away the hardware is super important for some use cases. A classic example is all of the platform-specific flavors of memcpy in the Linux kernel that are C/assembly hybrids hand-optimized for the SIMD pipelines of some CPUs.

C is a tool, Rust is a tool, Java is a tool, Python is a tool. Use the right tool for the job ¯\_(ツ)_/¯.

Re: Everything in C is undefined behavior

#484

Post by simonask »

tovej wrote: post #191
pjc50 wrote: post #132

Earlier quoted context omitted.

You missed the point: the pointer existing as a value of that type at all is UB, even if you never try to access anything through it and no corresponding machine code is ever emitted.

Yes? I agree with that. I don't really see the issue there. The computer will allocate data in aligned addresses, so you would have to be doing something weird to begin with to access unaligned pointers. And aligned access is always better anyway. I guess packed structs are a thing if you're really byte golfing. Maybe compressed network data would also make sense. But then I would assume you are aware of unaligned po…

String search algorithms would be one example, where a 64-bit register can be used as a “vector” containing 8x1 bytes.

Re: Everything in C is undefined behavior

#485

Post by zahlman »

shakna wrote: post #372
saagarjha wrote: post #359

Earlier quoted context omitted.

No this is irrelevant for making this decision

I've mentioned elsewhere the standards, and compilers as well, disagreeing with you here. But feel free to run against the various compilers through godbolt. [0] They won't optimise the branch away. Access to a volatile, must be preserved, in the order that they exist. No optimisation, UB or otherwise, is allowed to impede that. Because an access is a side-effect. [0] https://godbolt.org/z/85cGhq3Ta

Compilers not doing something is not a demonstration that they are not actually allowed to do that thing.

Re: Everything in C is undefined behavior

#486

Post by dwattttt »

nilamo wrote: post #397
aw1621107 wrote: post #384

Earlier quoted context omitted.

> that can easily be solved by a minute or two on godbolt... Unfortunately it's not that simple when it comes to UB. If the snippet in question does in fact exhibit UB then there's no guarantee whatever Godbolt shows will generalize to other programs/versions/compilers/environments/etc.

That's very funny to me. A) x is always removed. B) no, it's never removed if volatile. But neither person can prove what a compiler will actually do, despite claiming they'll always act a certain way given 5 lines of code.

I have watched a compiler flip between emitting the code I expected (despite it having UB), and emitting unexpected code after a minor update.

What you observe a compiler do when there's UB is not at all something you can rely on.

Re: Everything in C is undefined behavior

#487

Post by netrikare »

muvlon wrote: post #113

Yes there is tons of surprising and weird UB in C, but this article doesn't do a great job of showcasing it. It barely scratches the surface. Here's a way weirder example: volatile int x = 5; printf("%d in hex is 0x%x.\n", x, x); This is totally fine if x is just an int, but the volatile makes it UB. Why? 5.1.2.4.1 says any volatile access - including just reading it - is a side effect. 6.5.1.2 says that unsequenced…

[dead]

Re: Everything in C is undefined behavior

#488

Post by tialaramex »

saagarjha wrote: post #330
flohofwoe wrote: post #294

Earlier quoted context omitted.

> if two addresses are different ... Eh, if the compiler knows that two addresses are different at compile time, it also knows how big the difference is.

Usually this is not the case.

Indeed one of the fun LLVM bugs is that it can arrive at a situation in which it believes pointer A and pointer B are definitely not equal (weird given what's about to happen but OK that's potentially fine...) then we ask for their addresses† as integers X and Y, LLVM insists those integers aren't equal either because the pointers weren't (which as we're about to see is wrong) and then we subtract X - Y or Y - X and the answer either way is zero. Awkward. The integers were definitely equal.

† Although on a real modern CPU the pointer "is" just an address, notionally it has three components, the address, an address space (modern machines typically only have one) and a "provenance".

Re: Everything in C is undefined behavior

#489

Post by voakbasda »

chuckadams wrote: post #469
AnimalMuppet wrote: post #455

Earlier quoted context omitted.

Which is, if I understand correctly, the entire point of volatile. Don't use it if you don't want that behavior. And in fact, in the example given, if there is something (another thread or whatever) that can change the value of x, then you don't know what either number will be. Well, in that circumstance, without volatile, it may print the same number both times, but you still don't know what the number will be (unle…

If that behavior is the entire point, then I think the bigger point is that the spec should reflect that and not call it undefined.

I suspect that many undefined behaviors reflect the inability of the standard committee to come to a consensus on the nuances involved. “Punt to the implementers” is a way to allow every tool vendor to select their own expected behavior in those cases.

Re: Everything in C is undefined behavior

#490

Post by stellamariesays »

muvlon wrote: post #299
thomashabets2 wrote: post #279

Earlier quoted context omitted.

Author here. > It barely scratches the surface. I agree. The point of the post is not to enumerate and explain the implications of all 283 uses of the word "undefined" in the standard. Nor enumerate all the things that are undefined by omission. The point of the post is to say it's not possible to avoid them. Or at least, no human since the invention of C in 1972 has. And if it's not succeeded for 54 years, "try hard…

Fair enough! > And if it's not succeeded for 54 years, "try harder", or "just never make a mistake", is at least not the solution. And I 100% agree. UB is way overused by these standards for how dangerous it is, and as a consequence using C (and C++) for anything nontrivial amounts to navigating a minefield.

[flagged]
Post reply on HN