Re:Hardening the C++ Standard Library at scale
by steveklabnik on Saturday November 29, 2025 @02:15PM
(#46089987)
It is undefined behavior. You cannot make a claim about what it will always do.
[ Parent
| on HN ]
Re:Hardening the C++ Standard Library at scale
by AlotOfReading on Saturday November 29, 2025 @08:05PM
(#46092485)
As a fun example, I worked on a safety-critical system where accessing all-bits-zero pointers would trigger an IRQ that jumped back to PC + 4, leaving the register/variable uninitialized. Great fun was had any time there was LR corruption and CPU started executing whatever happened to be next in memory after function return.
Re:Hardening the C++ Standard Library at scale
by tonyarkles on Sunday November 30, 2025 @09:40AM
(#46097008)
Hahahaha well that behaviour is certainly fun!
I recently had a less wild but similarly baffling experience on an embedded-but-not-small device. Address 0 was actually a valid address. We were getting a HardFault because a device driver was dereferencing a pointer to an invalid but not-null address. Working backwards, I found that it was getting that invalid address not from 0x0 but rather from 0xC… because the pointer was stored in the third field of a struct and our pointer to that struct was null.
foo->bar->baz->zap
Foo = 0, &bar = 0xC, baz = invalid address, *baz to get zap is what blew up.