A Guide to Undefined Behavior in C and C++ (2010)

https://blog.regehr.org/archives/213

by GarethX • 1 year ago

79 64 1 year ago

blog.regehr.org

fsckboy2• 1 year ago

my opinion as a very experienced C system programmer:

there must be better sources to guide people than a poorly written and infantilizing article from 15 years ago.

staunton• 1 year ago

Being a very experienced programmer, I'm sure you know many such sources. Can you share any?

camel-cdr• 1 year ago

The C standard Annex J has a list of undefined behavior: https://port70.net/~nsz/c/c99/n1256.pre.html#J

ultrarunner• 1 year ago

Perhaps you could draw on your wealth of experience to write one. I’d love to read it!

rberg• 1 year ago

Agreed. Running with a basketball is very much possible, I'm unsure as to why John thinks otherwise.

jcranmer2• 1 year ago

My experience is that self-described "very experienced C system programmers" are simultaneously the people who are most in need of a good explainer on undefined behavior and the most likely ones to throw a conniption fit halfway through and stop reading, for the hallmark of a good explainer on UB is that it will explain that a) it exists for a reason; b) no, just doing a "little" UB isn't safe; and c) it's not the compiler's fault that things go awry when you do UB, it's the programmer's fault.

One of the blog posts I've long queued up for writing is "In defense of undefined behavior." It's only half-written, though, but the gist is justifying UB by pointing out that you can't optimize C code with it (via an example using pointer provenance), then pointing out why uninitialized values look weirder than you think by reference to the effects of system libraries, and then I would actually walk through why specification authors should reach for undefined behavior in various places.

raphlinus2• 1 year ago

Oh hey, I also have "in defense of undefined behavior" in the queue of blog posts I'd like to write some time, with that exact title. What a coincidence. That said, it's unlikely to get written as I have things that are more specific to my actual research ahead of it.

One of the things I'd want to say is that UB is a useful and accurate way to model what happens when, say, a program writes over memory used by the allocator. Languages like Odin might try to pretend they don't have UB, but in my opinion it's impossible to get there just by disabling certain compiler optimizations (see https://news.ycombinator.com/item?id=32800814 for an argument about this).

I see UB as essentially a proof obligation, to be discharged in some other way. A really good way is to have UB in the intermediate representation, and compile a safe language into it (with unsafe escape hatches when needed). But there are other ways, including formal methods, rigorous testing, or just being a really smart solo programmer who's learned how to avoid UB and doesn't have to work in a team.

Feel free to send me your draft.

fsckboy2• 1 year ago

most likely ones to throw a conniption fit halfway through and stop reading

listen to you, you didn't read the article it's clear, because the article doesn't agree with the rest of what you said. So, since you're not defending an article, you're just attacking me, which is pretty schmucky

pjmlp5• 1 year ago

If only folks would write code in a way that infantilizing article from 15 years ago aren't as actual as ever.

imtringued2• 1 year ago

In my opinion it's not infantilizing enough. If you are a C developer and have never heard of model checking, then you are grossly incompetent and should never be allowed near a computer.

jasonthorsness• 1 year ago

This is an area the newer languages get right - I don’t think Rust or Go has any undefined behavior? I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly.

steveklabnik3• 1 year ago

Safe Rust has no undefined behavior. Unsafe Rust does.

vlovich1237• 1 year ago

cough std::env::set_var cough :D.

jjmarr• 1 year ago

I wish they would have some kind of super strict mode for C or C++ where compilation fails unless you somehow fix things at the call sites to tell the compiler the behavior you want explicitly.

The C++ language committee _does not_ want to add more annotations to increase memory safety.

tialaramex2• 1 year ago

Several programming languages can testify to the fact than a Benevolent Dictator For Life is not a panacea. Several more than testify that having a Committee to design the language is likewise not a panacea. Perhaps uniquely C++ can clarify for us that both is in fact worse than either alone.

anon-39883• 1 year ago

Not even annotations. The committee standardize this https://en.cppreference.com/w/cpp/container/span/operator_at

So they clearly doesn't care so there's no point convincing them.

zyedidia• 1 year ago

I think data races can cause undefined behavior in Go, which can cause memory safety to break down. See https://research.swtch.com/gorace for details.

almostgotcaught2• 1 year ago

you realize UB is basically an escape hatch from the standard for compilers right? it's not like a flaw in the language, it's gaps negotiated by the standards committee (well for the most part i guess). so the reason new languages don't have UB is because new languages don't have multiple implementations (go definitely doesn't, does anyone use rust-gcc?).

Dylan168072• 1 year ago

You only need implementation-defined behavior to grease the wheels of multiple implementations. You don't need the gaping void of undefined for that use.

There's a big difference between "it'll be some number, not promising which one" and "the program loses definition and anything can break, often even retroactively".

wolvesechoes• 1 year ago

"go definitely doesn't"

What? gccgo, TinyGo, and GopherJS.

pjmlp5• 1 year ago

Older languages as well, those that weren't a copy-paste from C with extras.

Modula-2, Ada, Object Pascal, Eiffel, Delphi,...

guimplen• 1 year ago

The first example (signed integer overflow) is no longer valid in newer standards of C. Now it should use the two-complement semantics and no UB.

Rusky• 1 year ago

I believe they only standardized the two's-complement representation (so casts to unsigned have a more specific behavior, for example) but they did not make overflow defined.

LegionMammal978• 1 year ago

Yeah, signed integer overflow is as UB as ever. I've heard the primary reason for it is to avoid the possibility of wraparound on 'for (int i = 0; i < length; i++)' loops where the 'length' is bigger than an int. (Of course, the more straightforward option would be to use proper types like size_t for all your indices, but it's a classic tradition to use nothing but char and int, and people judge compilers based on existing code.)

pajko• 1 year ago

UB can be converted to ID by using -fwrapv (to "standardize" the wrapround, which does not necessarily help if the overflow was not intentional) or -ftrapv (generate an exception).

mwkaufma• 1 year ago

Despite the high frequency that alarmist "formatting you HDD" is cited in discussing UB, I've never seen it happen. Surely there exist real examples of catastrophic failures which could actually teach us something, beyond making a hyperbolic point.

vlovich1237• 1 year ago

It was intentionally hyperbolic tongue in cheek and understood to be as such. The reason is to fight through the discounting people (at least at the time) had that UB was just a segfault or something. Here’s a kernel exploit that was a result of UB [1]. It’s not hard to imagine that hypothetically UB in the kernel could result in “just so” corruption that would call the “format your HDD routine” even if in practice it’s extremely unlikely (& forensically it would basically be impossible to prove that it was UB that caused it).

https://lwn.net/Articles/342330/

AlotOfReading6• 1 year ago

One example is control flow bending [0], which uses carefully crafted undefined behavior to "bend" the CFG into arbitrary, turing complete shapes despite CFI protections. The author abused this to implement tic tac toe in a single call to printf for a prior obfuscated C contest [1].

Of course, that misses the real point that "formatting your HDD" is simply an allowed possibility rather than a factual statement on the consequences.

[0] https://www.usenix.org/conference/usenixsecurity15/technical...

[1] https://www.ioccc.org/2020/carlini/index.html

zombot• 1 year ago

The most horrifying aspect of UB is that it can affect your program without the instructions triggering it ever being executed. And many greenhorns don't know that or even believe it to be false. So the effects of Dunning-Kruger may be more severe in C(++) than in other languages.

maxlybbert3• 1 year ago

It’s not just “there’s a line in some file that’s undefined” partly because undefined behavior is often caused by the state of the world. Dereferencing a pointer is defined unless the pointer is invalid, and any particular pointer may be valid sometimes and invalid others.

But since a compiler can do anything when a program is ill-defined, if a line of code could be well-defined in some cases and ill-defined in others, a compiler is allowed to only handle the well-defined cases, knowing that it will do the “wrong” thing when something about the code is undefined (because in that case, there is no “right” or “wrong” behavior.

This does lead to weird things:

    auto val = *ptr;
    if (!ptr) {
        . . .
    }

The compiler can delete the “if” statement because the potential undefined behavior happens before the check. Either the pointer is valid when dereferenced (and the “if” statement gets skipped), or the pointer is invalid, and skipping the “if” statement is acceptable for “the compiler can do anything, even things that can’t be expressed in the language.” But it only does the weird things in cases where an invalid pointer would have been dereferenced.

hoseja• 1 year ago

Don't let people performatively horrified of undefined behaviour know about Gödel.

A Guide to Undefined Behavior in C and C++ (2010)

Related Stories