{"article":{"slug":"attention-people-who-think-ub-is-fine","title":"Attention people who think UB is fine","subtitle":null,"summary":"Thomas Habets follows up his post on undefined behaviour in C with a concrete example showing that UB is not 'at worst a segfault': the same line can run whatever is next in memory, write a random value and crash, or do what you naively expect.","content_type":"blog_post","language":"en","canonical_url":"https://blog.habets.se/2026/10/Attention-people-who-think-UB-is-fine.html","author":{"name":"Thomas Habets","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Blargh","url":"https://blog.habets.se/","listing_slug":null,"listing":null},"topics":[{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"C","slug":"c","url":"https://listedarticles.com/topics/c"},{"name":"Compilers","slug":"compilers","url":"https://listedarticles.com/topics/compilers"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":609,"reading_minutes":3,"published_at":"2026-10-22T00:00:00.000Z","added_at":"2026-10-23T23:15:01.884Z","updated_at":"2026-10-23T23:15:01.884Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/attention-people-who-think-ub-is-fine","markdown_url":"https://listedarticles.com/articles/attention-people-who-think-ub-is-fine.md","example":false,"citation":"Thomas Habets, Blargh. \"Attention people who think UB is fine.\" 22 Oct 2026. https://blog.habets.se/2026/10/Attention-people-who-think-UB-is-fine.html (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://blog.habets.se/2026/10/Attention-people-who-think-UB-is-fine.html"},"body_markdown":"# Attention people who think UB is fine\n\n2026-10-22,\nCategories: programming\n\nAfter [my post on undefined behavior in\nC](https://blog.habets.se/2026/05/Everything-in-C-is-undefined-behavior.html)\nsome people insisted that it’s demonstrably fine, we know what the code will\ndo, and at worst we’ll get a segfault.\n\nThis is false.\n\nHere’s an example.\n\n## C code\n\n```\n#include\n\n// Let's pretend this is a memory mapped device controlling\n// motors and gears and stuff.\nvolatile int device_command = 0;\n\nvoid serve_hot_chocolate() {\n device_command = 42;\n\n // Oh no, we spilled some hot chocolate, invoking UB.\n //\n // The definition of `std::unreachable()` is:\n // Invokes undefined behavior at a given point.\n std::unreachable();\n}\n\nvoid explode() {\n device_command = 3;\n}\n```\n\n## Example assembly output\n\nWith GCC 16.2 with `-O1`.\n\n```\n\"serve_hot_chocolate()\":\n mov DWORD PTR \"device_command\"[rip], 42\n\"explode()\":\n mov DWORD PTR \"device_command\"[rip], 3\n ret\n\"device_command\":\n .zero 4\n```\n\nRuh roh. Exploding chocolate! The function `explode()` will be executed, even\nthough it was never called!\n\n[godbolt link](https://godbolt.org/z/Y5844eTKe)\n\n## Another example: dereferencing a null pointer\n\nSome people insisted that dereferencing a null pointer is *fine*. It’ll just\ntry to access address zero! And these people supposedly know what happens when\nyou try: if nothing is mapped there, you’ll get a segfault.\n\nAgain, not true.\n\nLet’s say we change `std::unreachable()` to `int* ptr = nullptr; *ptr = 99;` in\nthe previous example. Now we [get this](https://godbolt.org/z/efqKrzefa):\n\n```\n\"serve_hot_chocolate()\":\n mov DWORD PTR \"device_command\"[rip], 42\n mov DWORD PTR ds:0, 0\n ud2\n```\n\nCurious, eh? First it writes zero, **not** 99, to memory address zero. Then it\ncrashes the program using an invalid instruction. The number 99 never appears\nin the generated program. But the null pointer write does. Presumably the null\npointer write is done in order to improve debugger error messages.\n\nNow let’s check [clang with godbolt](https://godbolt.org/z/86M7MWTT8):\n\n```\n\"serve_hot_chocolate()\":\n mov dword ptr [rip + \"device_command\"], 42\n\n\"explode()\":\n mov dword ptr [rip + \"device_command\"], 3\n ret\n\n\"device_command\":\n .long 0\n```\n\nAgain we get exploding chocolate.\n\n## Let’s do some pointer arithmetic on the null pointer\n\nOk, so what happens if we add `ptr += 10`. That’s UB for three reasons:\n\n1. using a null pointer for anything other than comparison against other pointers,\n2. even if an object would be valid at the null pointer (which it’s not),\n creating a pointer that points outside that object, or if an array, beyond\n one-past the array, is UB,\n3. even if that were valid (which it’s not), we then dereference the address.\n\nLet’s [try it](https://godbolt.org/z/8z6hPPsvG).\n\n```\n\"serve_hot_chocolate\":\n mov DWORD PTR \"device_command\"[rip], 42\n mov DWORD PTR ds:40, 99\n ret\n```\n\nWow. *Now* it did what someone naively would expect, taking the code at face\nvalue. Lucky.\n\nWhy did GCC (and clang, by the way) not detect that `*(ptr + 10) = 99` is\nequally UB as `*ptr = 99`, and do the same thing?\n\nWrong question. No compiler is obligated to “detect” UB at all. Looks to me\nlike GCC and clang, if we want to anthropomorphize them, saw “oh, null pointer\ndereference? Well that can’t happen, so I’ll stop emitting instructions for\nthis function, to save on the binary size”. Because of the [halting\nproblem](https://en.wikipedia.org/wiki/Halting_problem), it cannot in the\ngeneral case know if the code will ever be executed.\n\n## So what does UB do?\n\nAnything. I have now demonstrated three things UB can do, when UB was triggered\nin the same place:\n\n1. Run whatever happens to be next in memory (exploding chocolate).\n2. Store a (for all intents and purposes) *random* value at address zero (wrote\n zero, not 99), and then deliberately crash.\n3. Do what one would naively expect: write the value to the address seen in the\n code at face value.\n\nAnd to think that some people don’t believe in [nasal\ndemons](https://en.wikipedia.org/wiki/Undefined_behavior).\n","body_html":"

Attention people who think UB is fine

\n

2026-10-22,\nCategories: programming

\n

After my post on undefined behavior in\nC\nsome people insisted that it’s demonstrably fine, we know what the code will\ndo, and at worst we’ll get a segfault.

\n

This is false.

\n

Here’s an example.

\n

C code

\n
#include<utility>\n\n// Let's pretend this is a memory mapped device controlling\n// motors and gears and stuff.\nvolatile int device_command = 0;\n\nvoid serve_hot_chocolate() {\n        device_command = 42;\n\n        // Oh no, we spilled some hot chocolate, invoking UB.\n        //\n        // The definition of `std::unreachable()` is:\n        //     Invokes undefined behavior at a given point.\n        std::unreachable();\n}\n\nvoid explode() {\n        device_command = 3;\n}
\n

Example assembly output

\n

With GCC 16.2 with -O1.

\n
"serve_hot_chocolate()":\n        mov     DWORD PTR "device_command"[rip], 42\n"explode()":\n        mov     DWORD PTR "device_command"[rip], 3\n        ret\n"device_command":\n        .zero   4
\n

Ruh roh. Exploding chocolate! The function explode() will be executed, even\nthough it was never called!

\n

godbolt link

\n

Another example: dereferencing a null pointer

\n

Some people insisted that dereferencing a null pointer is fine. It’ll just\ntry to access address zero! And these people supposedly know what happens when\nyou try: if nothing is mapped there, you’ll get a segfault.

\n

Again, not true.

\n

Let’s say we change std::unreachable() to int* ptr = nullptr; *ptr = 99; in\nthe previous example. Now we get this:

\n
"serve_hot_chocolate()":\n        mov     DWORD PTR "device_command"[rip], 42\n        mov     DWORD PTR ds:0, 0\n        ud2
\n

Curious, eh? First it writes zero, not 99, to memory address zero. Then it\ncrashes the program using an invalid instruction. The number 99 never appears\nin the generated program. But the null pointer write does. Presumably the null\npointer write is done in order to improve debugger error messages.

\n

Now let’s check clang with godbolt:

\n
"serve_hot_chocolate()":\n        mov     dword ptr [rip + "device_command"], 42\n\n"explode()":\n        mov     dword ptr [rip + "device_command"], 3\n        ret\n\n"device_command":\n        .long   0
\n

Again we get exploding chocolate.

\n

Let’s do some pointer arithmetic on the null pointer

\n

Ok, so what happens if we add ptr += 10. That’s UB for three reasons:

\n
  1. using a null pointer for anything other than comparison against other pointers,

  2. even if an object would be valid at the null pointer (which it’s not),

    creating a pointer that points outside that object, or if an array, beyond\n one-past the array, is UB,

  3. even if that were valid (which it’s not), we then dereference the address.
\n

Let’s try it.

\n
"serve_hot_chocolate":\n        mov     DWORD PTR "device_command"[rip], 42\n        mov     DWORD PTR ds:40, 99\n        ret
\n

Wow. Now it did what someone naively would expect, taking the code at face\nvalue. Lucky.

\n

Why did GCC (and clang, by the way) not detect that *(ptr + 10) = 99 is\nequally UB as *ptr = 99, and do the same thing?

\n

Wrong question. No compiler is obligated to “detect” UB at all. Looks to me\nlike GCC and clang, if we want to anthropomorphize them, saw “oh, null pointer\ndereference? Well that can’t happen, so I’ll stop emitting instructions for\nthis function, to save on the binary size”. Because of the halting\nproblem, it cannot in the\ngeneral case know if the code will ever be executed.

\n

So what does UB do?

\n

Anything. I have now demonstrated three things UB can do, when UB was triggered\nin the same place:

\n
  1. Run whatever happens to be next in memory (exploding chocolate).

  2. Store a (for all intents and purposes) random value at address zero (wrote

    zero, not 99), and then deliberately crash.

  3. Do what one would naively expect: write the value to the address seen in the

    code at face value.

\n

And to think that some people don’t believe in nasal\ndemons.

","headings":[{"level":1,"text":"Attention people who think UB is fine","id":"attention-people-who-think-ub-is-fine"},{"level":2,"text":"C code","id":"c-code"},{"level":2,"text":"Example assembly output","id":"example-assembly-output"},{"level":2,"text":"Another example: dereferencing a null pointer","id":"another-example-dereferencing-a-null-pointer"},{"level":2,"text":"Let’s do some pointer arithmetic on the null pointer","id":"let-s-do-some-pointer-arithmetic-on-the-null-pointer"},{"level":2,"text":"So what does UB do?","id":"so-what-does-ub-do"}]}}