Everything in C is undefined behavior • Hacker News Board

Re: Everything in C is undefined behavior

#331

Post by matheusmoreira » Wed, May 20, 2026, 11:33 AM UTC

bluGill wrote: post #312

matheusmoreira wrote: post #291

Earlier quoted context omitted.

Any reason the hardware pointer can't be accessed via the packed structure? https://news.ycombinator.com/item?id=48205371

however you certainly can do that. The point of unaligned is the hardware can't load it from a single memory location in one address. It needs two accesses. And in that time, the value of one of the two addresses that the hardware has to load can change. I would hope you're not so stupid as to design hardware that relies on this, but the fact is it certainly is possible for someone to do that. And if you do that, the…

Yeah, the unaligned accesses aren't going to be atomic unless the hardware supports it.

> And in that time, the value of one of the two addresses that the hardware has to load can change.

You mean volatile addresses that could spontaneously change in the middle of the reads? Like memory mapped I/O addresses?

I would expect these to have stricter access requirements than arbitrary general purpose memory locations.

> I would hope you're not so stupid as to design hardware that relies on this

You and me both.

> And if you do that, there is nothing that the compiler or the standard can do. It can't be done correctly

Anything that does that is broken and terrible anyway. It really shouldn't contaminate language design. It's the sort of thing that compilers should be adding attributes for, rather than constraining the language to the point nothing works correctly and making us use attributes on everything to restore some sane baseline behavior.

Re: Everything in C is undefined behavior

#332

Post by rocketrascal » Wed, May 20, 2026, 11:34 AM UTC

pjc50 wrote: post #128

layer8 wrote: post #107

Earlier quoted context omitted.

That’s true in other languages as well. Any programmatic task can end up being an exploit vector.

No? That's the whole point of formal verification? You can even kind of retrofit this to C. The classic example is "sel4". You just need a set of proofs that the code doesn't trigger UB. This ends up being much larger and more complicated than the C itself.

You can fail to verify something which you actually wanted to verify (i.e you made a proof of something else instead of the thing that mattered). See WPA2 KRACK as an example.

Re: Everything in C is undefined behavior

#333

Post by 1718627440 » Wed, May 20, 2026, 11:34 AM UTC

IshKebab wrote: post #287

1718627440 wrote: post #206

Earlier quoted context omitted.

> They could easily say something like "non-atomic misaligned accesses either succeed or trap" or something like that. That means that the compiler must emit the read, even if the value is already known or never used, as it might trap. There is a reason for the UB!

No it doesn't. Compilers are only required to emit the read for volatile types. If the type is non-volatile, misaligned, and can be optimised out then it would be perfectly fine to omit it (that would be the "succeed" option).

If a trap is observable behaviour, then the compiler either needs to add code, that checks for the condition and then traps explicitly or it needs to actually perform the read. Currently it can be optimized out, because it is UB.

Re: Everything in C is undefined behavior

#334

Post by gpderetta » Wed, May 20, 2026, 11:36 AM UTC

1718627440 wrote: post #235

gpderetta wrote: post #176

Earlier quoted context omitted.

The issue is that the list is infinite (anything not specified is UB), so actually removing any finite amount of UB from the list won't make it shorter. (only slightly tongue-in-cheek, I do believe that removing silly things is worthwhile).

The list of UB categories and rules is not infinite. The list of UB programs is, as is the list of all non UB programs.

It is not obvious to me that the list of categories is not infinite (unless the final category is "everything else" of course)

Re: Everything in C is undefined behavior

#335

Post by lll-o-lll » Wed, May 20, 2026, 11:37 AM UTC

saagarjha wrote: post #306

muvlon wrote: post #299

Earlier quoted context omitted.

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.

What should the behavior above be defined to do?

HCF

Re: Everything in C is undefined behavior

#336

Post by saagarjha » Wed, May 20, 2026, 11:37 AM UTC

mbrock wrote: post #258

simonask wrote: post #246

Earlier quoted context omitted.

> just That word is carrying a lot of weight here. Compilers are unbelievably complex these days, and it's impossible for any one human to fully understand the entire compilation process, including the effects of any arbitrary combination of compiler flags. Any assumptions you have about what the compiler does in the face of UB will collapse on the next patch release of that compiler, or the moment somebody changes t…

Yet the standard does not tell you what the compilers do. Linux works on a wide variety of platforms. It also relies on those platforms behaving predictably with respect to what the standard leaves undefined. This description of ISO UB as a totally insane wonderland of random, malevolent semantics just doesn't describe reality.

Up until the compilers do something to your code that you don’t understand.

Re: Everything in C is undefined behavior

#337

Post by crote » Wed, May 20, 2026, 11:38 AM UTC

ErroneousBosh wrote: post #302

elch wrote: post #126

Earlier quoted context omitted.

If you don't like JIT/JVM there's GraalVM Native Image. https://www.graalvm.org/latest/reference-manual/native-image... In the past you could use e.g. Excelsior JET.

Great, can you fit it into 768 bytes of flash and 64 bytes of RAM?

It isn't 1970 anymore. You can get 32-bit ARM MCUs with tens of kilobytes of flash and multiple kilobytes of RAM for less than 10 cents.

We've long since reached a point where chips are cheap enough to be disposable. They are included in paper transit tickets and price tags. There is basically no market left where your volume is small enough that custom application-specific ICs aren't an option, but your volume is large enough that the cost of a few additional kilobytes of memory isn't massively outweighed by the developer time saved.

Want several megabytes of RAM and flash to run Java? That's the price of a cup of coffee!

Re: Everything in C is undefined behavior

#338

Post by [deleted] » Wed, May 20, 2026, 11:38 AM UTC

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…

[deleted]

Re: Everything in C is undefined behavior

#339

Post by frollogaston » Wed, May 20, 2026, 11:38 AM UTC

sethev wrote: post #182

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…

Yes, there is a data race there. The value of a volatile can be changed by something outside the current thread. That’s what volatile means and why it exists. Edit: thread=thread of execution. I’m not making a point about thread safety within a program.

Was going to say the same thing until I saw this comment. volatile is defined the way I'd expect, plus it's a strange code example.

Re: Everything in C is undefined behavior

#340

Post by lelanthran » Wed, May 20, 2026, 11:39 AM UTC

saagarjha wrote: post #322

lelanthran wrote: post #160

Earlier quoted context omitted.

> They understand that all types "are" just bytes and that all pointers "are" just register-sized integer addresses, because that's how the hardware works and has worked for decades. I'd clarify this with "They understand that all values are just bytes" . > Meanwhile, the actual computers we have been using for decades have no problems actually just loading 4 bytes through any arbitrary pointer with zero overhead. It…

Turning undefined behavior into implementation defined behavior is rarely a fix, though.

It's a fix that removes the most pointy part of UB.

"Going past the end of the array results in addressing arbitrary values" I can live with. "Going past the end of an array results in anything happening" is a hard sell.