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

341–350 of 748 posts

Re: Everything in C is undefined behavior

#341

Post by shakna »

u8080 wrote: post #328
shakna wrote: post #296

Earlier quoted context omitted.

"volatile" tells the compiler it is _not_ safe to optimise away any read or write, so it can't just optimise that section away at all. > An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2…

When compiler decides something is UB aka "result of this code is not defined and could be any" it selects the most performant version of undefined behavior - doing nothing by optimizing code away.

The compiler is not free to remove accesses to something marked volatile - its defined as a side-effect.

Volatile means something else may be acting here. Something else may install anything into the register at any time - and every time you access.

The compiler is required to preserve the order of accesses. In almost every C compiler, today, there are almost no optimisations the moment a volatile is introduced, for this reason.

Re: Everything in C is undefined behavior

#343

Post by imtringued »

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…

Memory mapped IO sends a read request to a peripheral which is allowed have side effects in the background and return two different values upon a read. You can think of it as a synchronous RPC request.

The lack of argument sequencing feels utterly petty however.

Re: Everything in C is undefined behavior

#344

Post by jeffffff »

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?

Compilation error

Re: Everything in C is undefined behavior

#345

Post by saagarjha »

elnatro wrote: post #252

Is there a way to avoid undefined behavior Im C then? Could we write a new C compiler that adds some checks and fixes (e.g. raise documented exceptions) to each undefined behavior?

Not all of them but there are many tools that can try to define behavior for this code to help shake them out of your codebase.

Re: Everything in C is undefined behavior

#346

Post by frollogaston »

quelsolaar wrote: post #62

The 5 stages of learning about UB in C: -Denial: "I know what signed overflow does on my machine." -Anger: "This compiler is trash! why doesn't it just do what I say!?" -Bargaining: "I'm submitting this proposal to wg14 to fix C..." -Depression: "Can you rely on C code for anything?" -Acceptance: "Just dont write UB."

"Just don't write UB" sounds like still part of the bargaining stage at best

Re: Everything in C is undefined behavior

#348

Post by saagarjha »

spacedcowboy wrote: post #298
simonask wrote: post #256

Earlier quoted context omitted.

The point I'm getting at is that your definition of "simple" (a word that should be banned among programmers) is not useful, if it is even meaningful. The brainfuck example is "simpler": Only 8 kinds of tokens! Not really useful, though. The cognitive load of _actually delivering software_ written in C is immensely greater than doing so with Swift, or Rust, or Python, or Java, even Zig, despite all of those leveragin…

Calling something "simple" to use and learn is a valid use of the word, sorry. Not going to stop doing that. > The cognitive load of _actually delivering software_ written in C is immensely greater than doing so with Swift, or Rust, or Python, or Java, even Zig, despite all of those leveraging much heavier machinery in order to deliver a friendlier abstract model for you to program against Sorry, I couldn't disagree…

> I've got 40 years of programming in C so far, and the nightmare stories ran out after the first few years.

You need to find something more interesting to do ;)

Re: Everything in C is undefined behavior

#349

Post by matheusmoreira »

saagarjha wrote: post #326
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

The same reason you probably aren’t adding manual alignment fixes to your code?

No reason at all, then. Because I am manually dealing with alignment in my code.

Wrote a lisp, its bytes type supports reading and writing integers at arbitrary locations within the buffer. Test suite exercises aligned and unaligned memory access for every C integer type. Also wrote my own mem* functions, dealing with alignment in those was certainly a fun exercise. It wasn't necessary, I just wanted the performance benefits.

Re: Everything in C is undefined behavior

#350

Post by saagarjha »

mbrock wrote: post #157
oersted wrote: post #92

Earlier quoted context omitted.

UB doesn't mean that it is not specified (actually it is often very well specified), it means that compilers can and do assume that such code patterns will not be present. Those cases may not be considered and can lead to unexpected behaviour. Additionally, some (most?) UB is intentionally UB so that optimisers are free to do fancy tricks assuming that certain cases will never happen. Indeed, this is required for hig…

undefined behavior is the behavior of code patterns "for which this International Standard imposes no requirements" and the behavior is in fact almost always predictable and agreed upon by compiler vendors and the users of the language, which is why you are able to use programs that rely on undefined behavior probably every single second you are using the computer edit: for example I'm typing this into Safari which m…

It matters when your JSC JIT is full of security holes
Post reply on HN