I wouldn’t say “nobody ever”, but I would say it’s important to carefully consider whether it is really worthwhile using in any particular instance. It’s certainly safer, in the sense of reducing risk of UB, not to use it. In select cases, though, it might allow for significantly better optimisation of code.

score 1 · canonical

You cannot write code that depends on UB.

There are also standards, such as POSIX, that themselves define some things which standard C leaves undefined.

And that does not matter.

I C says an API is UB if used in a specific way, it does not matter what the API implementation does or says. If the C standard says that is UB, it puts no requirements on the compiler.

There is no difference between using an API that posix says is defined but C says is not vs dividing by zero, or overflowing an integer.

If you write C code that depends on implementation defined behavior (POSIX), but C says is UB, your C code is wrong.

The fact that you can get away with it today, doesn’t magically make your code correct. It does not mean that it will work if you change header orders, or inlining changes, or anything else.

If your code invokes UB according to the language, you are not writing conforming C. Maybe your compiler allows it (for example -fwrapv, -ftrapv, -fno-delete-null-pointer-checks, etc) but that is no longer conforming C, and your program is wrong vs the standard: any other C compiler is free to assume your UB code does not occur, or is unreachable, etc.

score 1 · canonical

I think it comments like yours and posts like this contribute to an extremely negative sentiment around the state of undefined behaviour in languages like C and C++.

It is not being “negative”, it is being precise. The sentiment of “I can do UB if I know what the hardware does” is way too wide-spread. For example, even in the early days of Rust we had code in major crates that performed unaligned loads on x86 saying that it’s fine on this hardware, and in C this remains a common pattern – but it’s UB and clang/LLVM will “miscompile” such code under the right circumstances.

Maybe you have already understood all this and hence find the examples in the post needlessly alarming. But the sad reality is that many, many programmers have not, and in fact C is still taught to people in a way that gives them the wrong idea about UB. Until the majority of C/C++/Rust programmers has learnt to take UB seriously and to treat it with precision, we will need posts and comments like the GP. (I think in Rust we are doing quite well here, but we’ll never really be done educating people.)

A precise treatment of UB can include “get the compiler to document that some case is not UB”. As people like to point out in these discussions, compilers are totally allowed to refine the standard and define behavior that the standard leaves as UB. They don’t have to wait for the committee to force them to remove UB. However, to my knowledge, neither GCC nor clang do this. Without a clearly defined contract, it becomes impossible to precisely analyze whether a piece of code actually is correct or not. Sanitizers, hardened compilation modes, UB-checking tools like Miri – all of those can only work of there is a precise agreed-upon contract around UB. The lack of such a contract for C and C++ is really the main problem in my eyes: the standard leaves too many things undefined that practical systems programming needs, and compiler vendors do not bother to document any extra guarantees. Both sides are to be blamed for the mess that we find ourselves in as a result.

score 1 · canonical

Your complaint is … you agree that UB has the qualities outlined by TFA, ~olliej and others, but you think the comments should be more positive somehow?

What you can do is: learn C. Learn what the standard guarantees, what choices it leaves up to implementations (implementation-defined behavior) and what it labels undefined behavior. Then try to avoid writing code which invokes undefined behavior. That’s it. Don’t do what so many wants to do and dismiss it because “I only target one platform” because it’s not that simple.

Here’s a few notes about types and aliasing:

• Every object has an “effective type”. The effective type of stack-allocated objects have the type you declared them as (e.g an int foo has effective type of int, a struct sockaddr_in addr has the effective type of struct sockaddr_in).
• Heap-allocated memory starts out without an effective address (yes, malloc is magic; you may treat memory obtained from mmap the same way). They gain an effective type the moment you write anything to it (either by writing through a pointer or through functions like memcpy).
• Do not dereference an object of effective type X through a pointer type of type Y. If you have an int, don’t dereference it through a pointer to float. There are two exceptions:
  • You can look at the memory of any object by going through a char * or unsigned char *. This is how e.g memcpy can copy bytes without knowing the effective type.
    • Note that this does not work the other way: if you have an object of effective type char (e.g as a part of a stack-allocated array char[N]), you may not access it through a pointer to some other type. This has implications for how you can use stack-allocated buffers.
  • If you have two struct types X and Y with a “common initial sequence” (meaning the first few fields are the same types in the same order), you may have an object with effective type X and look at those common initial fields through a pointer to Y.

The consequence of this is that you should be using memcpy a lot more; if you have some memory buffer and you know there’s an int at offset K, don’t make an int * to it, instead make a local int variable and memcpy the data. The compiler will figure out how to make it fast.

Then there are the obvious ones: don’t dereference null pointers, don’t overflow integers (not even through addition or bit shifting), don’t write outside of memory you allocated.

There’s more of course, this is just what I remember off the top of my head right now as things which might catch people off guard if they learned about C by learning that “memory is a big flat array of bytes and pointers are indexes into that array”. That is true when you’re implementing C but not when you’re programming in C.

Then there are kinds of UB which you can safely ignore for a given platform. For example, ISO C disallows casting between an object pointer (such as void *) and a function pointer; however the POSIX dynamic linker API provides one function dlsym which returns a void *, which the caller is expected to cast to a function pointer type and then call. As a result, every implementation which supports the POSIX dynamic linker API allows casting between object pointers and function pointers. And both GCC and Clang (and probably others) explicitly allow you to violate the effective type rules by going through a union.

Maybe I should write a blog post about this…

score 1 · canonical

it is impossible to write an optimizing compiler that behaves sensibly in the presence of UB. The only real solution, which pretty much every programming language in the world other than C and C++ do, is to make it harder or even impossible to have UB in your code.

In fact, authors like Chris Lattner have even been quite explicit in pointing out “advantages of undefined behaviour in C”

UB is really useful to languages such as C. The key point with say Rust, is that it’s basically like C, useful in the same situation, and has tons of undefined behavior which is really useful. But you can’t actually hit any UB without using unsafe {}. We get to have the advantages of UB while making things much easier for the programmer.

This is useless! Here, I’ve just made a language called Lil-C, which exactly like C, except that every UB is formally defined to trap. It is safe! And it can run any C program! Have I just done anything useful? No!

This actually seems like it would be quite useful…?

I disagree with Matklad, but only to a degree. If you specified such a thing, but had no way to run it efficiently, it would be of limited usefulness. Good to run some old non-performance-critical codebase you don’t want to port to another language, but useless for anything who has a reason to choose to use C today. If it’s fast, like if you have CHERI hardware, then it’d be a lot more useful.

Anyway, by this post and the above comment’s reasoning, it is not possible to constrain the consequence of undefined behaviour; as a result, it is not possible to retroäctively detect that it has performed an undesirable transformation. However, since undefined behaviour arises as an emergent property across multiple (desirable, reasonably optimisations,) I also cannot simply read through a lists of undefined behaviours in C and expect to be able to avoid triggered it intentionally. Understandably frustrating!

it is not possible to retroäctively detect that it has performed an undesirable transformation

I don’t think it’s possible to even know what is or isn’t a desire transformation in general.

However, since undefined behaviour arises as an emergent property across multiple (desirable, reasonably optimisations,)

UB doesn’t arise from anything like that. Whether code is UB is an inherent property of the code and the language spec. And since the language spec isn’t a formal mathematical model, it’s sometimes very difficult to know what is well-defined.

Even with zero fancy optimization passes, you’d still suffer! A stray ińvalid write can still mess with your return pointer, or some important code in libc, or whatever, and totally mess up your program.

In other words, even if I won’t rewrite my C codes, and even if I do want to make substantive changes to them, and even if I know I will suffer from the consequences of undefined behaviour, and even if these will be difficult to avoid through additional mechanism or additional diligence, I still have some obligation-to and corresponding freedom-of action. What do I do in the next (… maybe the last? … hopefully the last?) hundred thousand lines of C that I write? Just flail and drown?

I would say that C and C++ are simply completely horrible languages that ought to cease to exist. In practice, this is difficult. Perhaps the easiest option would be to elect political leaders all over the world who are on board with mandating CHERI for all everything.

score 1 · canonical