Certain constructs or conditions in programming just are not allowed. Languages such as Java or Swift handle these by raising an error when encountered. C and C++ on the other hand say 'Anything could happen, might error, might work, might work some of the time.'
What are the advantages of leaving behavior undefined as opposed to raising an error on an invalid program?
The C89 standard, section 3.16, defines:
undefined behavior: Behavior, upon use of a nonportable or erroneous program construct, or of erroneous data, or of indeterminately-valued objects, for which this International Standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
And the 1999 C Rationale explains why:
Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.
The C99 standard, section 3.4.3, words it slightly differently, turning the second sentence into an explanatory note:
undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements
NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
EXAMPLE An example of undefined behavior is the behavior on integer overflow.
Note that in the second sentence, the word "permissible" was changed to the word "possible".
This has resulted in two schools of thought in the C and C++ community.
The first group, largely made of C programmers, argues that the second sentence in the C89 standard was normative: it described the set of permissible behaviours. So "undefined behaviour" is only "undefined" in the sense that the standard does not require which of the permissible behaviours an implementation may do.
The second group, largely made of "standards lawyers" and open source C compiler implementors, point out that, under ISO rules, moving the second sentence to an explanatory note and changing the word "permissible" to "possible" means that it is not normative. These are merely possible behaviours, but because the standard imposes no requirements, any behaviour is possible.
This is also known as a "nasal demon", because the compiler making demons fly out of your nose is also a possible behaviour.
This is a problem for many C programmers, since it meant that WG14 declared a lot of customary C usage to be undefined behaviour. Chris Lattner of LLVM put it this way: "huge bodies of C code are land mines just waiting to explode."
So, for example, if you ever write this:
i << 32
If i is a 32-bit integer, shifting it left by 32 is undefined behaviour. According to the second interpretation, any instance of this anywhere on an execution path renders the whole program semantically meaningless. And specifically, a compiler may assume that undefined behaviour can never happen and optimise your code accordingly.
This brings us to SPECint, the standard suite of integer benchmarks maintained by the Standard Performance Evaluation Corporation. This set of benchmarks is how C compiler vendors evaluate and market their code-generation and optimisation performance.
One of the benchmarks is 464.h264ref, which is a reference implementation of H.264/AVC video coding. It contains the following interestingly-written function:
int d[16];
int SATD (void)
{
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
Please ignore the code quality for a moment. What I want you to notice is the for loop, specifically dd=d[++k]. On the last iteration of the loop, this reads one element past the end of the array. The value is never used, so the read is actually safe. Nonetheless, this is technically undefined behaviour.
Apparently nobody noticed until a pre-release version of GCC 4.8 optimised it. The compiler reasoned:
d cannot possibly happen.k cannot be greater than 15 before the array access d[++k].k<16 is always true.And the final generated code was this:
SATD:
.L2:
jmp .L2
It was fixed before GCC was released, and it now gives a warning. Let it also be a warning to you.
Checking for errors at runtime is quite expensive. Branching operators massively are slow instructions, especially since they prevent many optimizations. If every basic operator needed a sanity check it would massively add to the runtime of your program.
On the other hand, a lot of things that are "undefined behavior" are quite easily checked by the programmer. Languages like C and C++ choose to trust the programmer to check these things properly and therefore benefit from faster code.
Languages like Rust do do more checks by default but even then the checks can be disabled for developers who know for sure they would pass.
Languages can have multiple implementations, and multiple versions of the same implementation. Implementing some functionality in one version might be much harder than another, possibly because of platform constraints.
You could specify the behavior of one version and force other implementations to implement it but it would be slow, inconvenient, and might mean your language can't even run on some platforms.
Implementors also want freedom to update the implementation over time. Maybe a faster algorithm is discovered but it behaves slightly differently in situations where it shouldn't really be used anyways. (eg. sorting a array with a non-transitive comparison function)
Thus, just providing some constraints for how some functionality must be handled allows implementors to choose the best implementation without fear of breaking existing programs.
Compiled languages often have a optimizer. Optimizers massively increase performance but need to make assumptions about the code to work. CPUs nowadays are able to execute many instructions at once so long as they use different parts of the chip and a whole bunch of very complex rules are also followed. Compilers will rearrange your instruction so that multiple instructions can be run at once.
To do this, the compiler will build a graph of the dependencies of each instruction so it can guarantee nothing will be run before the data it depends on. However, the compiler needs to make assumptions to do this.
For example it needs to know none of the data it needs will be written to by another thread. It may assume that no pointers alias. It may also assume no integers overflows.
These things are very hard to check for a compiler but relatively easy to check for a programmer. Considering the huge performance benefit this is usually considered worth it.
Besides performance and ease of writing an implementation, there is one other reason for undefined behavior.
If some property is impossible to check for and cannot be defined because it's unpredictable by nature, you have to make it undefined.
The best example is data races and race conditions. You can't check for them in the compiler (without designing the language around it, like Rust), and they can have unpredictable results, so you must make their behavior undefined.
int or an object reference that is written by one or more threads and read by one or more threads, each read may independently yield either the value held at the barrier, or any value that was written after it, and at the next sequencing barrier the object may receive any of the values that was written, but those are the only possible things that can happen.
$\endgroup$
hashCode function to safely cache its result without memory barriers. If one thread hashes a string and then another does so later, but there hasn't been any memory barriers between the operations, the latter thread might not see the cached result from the first and thus perform a redundant hash calculation, but the lack of memory barriers would have no consequence beyond the wasted effort of computing the hash again.
$\endgroup$
The premise of undefined behavior is assuming that erroneous conditions never happen. The responsibility of checking and avoiding such conditions is placed on the programmer and not on the implementation. While many languages check for exceptional conditions every time one may happen, C and C++ do not. This removes safety, because the underlying behavior of the undefined construct can be unpredictable, but improves performance and ease of writing an implementation, as less (redundant?) checks are being made by the implementation, because it is assumed that the programmer did their job.
If C were to require that dereferencing NULL yielded a runtime error, the compiler may have to spend time tracking which pointers can be NULL and/or insert NULL tests that manually crash the program at every point a pointer is dereferenced. Instead, the anything goes aspect of undefined behavior permits the compiler to assume these will never happen and omit checks. Because any possible unpredictable behavior result from omitting the test would be valid 'undefined behavior.'
fopen(name,"r") to read a file that some other program wrote in binary mode, but...
$\endgroup$
fopen implementation to return null, or else translate the file in a documented fashion, an implementation that does one of those things would be preferable to one that would arbitrarily corrupt the memory, but if the underlying OS would corrupt memory when attempting to perform such an action, a C implementation can't very well be required to prevent that.
$\endgroup$
The point about UB is that the language – the compiler, or the interpreter – does not have to worry about extreme or edge cases. It's the programmer that has to worry about such situations. In other words, "Undefined Behaviour" takes a lot of worrying away from the language itself, and puts it back onto the shoulders of the user of the language. Whether that is a good idea or not is up for discussion.
Consider the following C function. Suppose this function is put into a separate file (separate "compilation unit"):
void f(int *x) {
x[100] = 25;
}
This compiles without problems, even though at compile time it is not known what x points to. But the compiler is happy to oblige anyway: it takes the pointer x, it adds to it 100 times the size of an integer, and it attempts to write "25" into the resulting memory location. Whether this succeeds or not, and what the actual result is, depends on how this function is called.
It could be that (in the application that uses f) we have something like
int a[1000];
f(a);
in which case invoking f won't do anything unusual or undefined. But it also could be that the function is invoked as
int a[10];
f(a);
In this case we simply cannot say what the result of this function call is. It could attempt to write to memory which the current process doesn't have access to; this would result in an "Access violation" or "Segmentation fault" error, or something similar; possibly resulting in program termination. But it is also possible that this function will overwrite some other memory belonging to the same process – with completely unpredictable results!
And that's the whole point of "undefined behaviour". The language itself (the compiler or the interpreter) does not have to worry about special cases – for example it does not have to check that a pointer points to a valid memory area (that the current process has access to). This shifts a lot of responsibility from the language itself onto its users!
From the ISO C++ wiki's FAQ item, "Why are some things left undefined in C++?":
Because machines differ and because C left many things undefined. For details, including definitions of the terms “undefined”, “unspecified”, “implementation defined”, and “well-formed”; see the ISO C++ standard. Note that the meaning of those terms differ from their definition of the ISO C standard and from some common usage. You can get wonderfully confused discussions when people don’t realize that not everybody shares definitions.
This is a correct, if unsatisfactory, answer. Like C, C++ is meant to exploit hardware directly and efficiently. This implies that C++ must deal with hardware entities such as bits, bytes, words, addresses, integer computations, and floating-point computations the way they are on a given machine, rather than how we might like them to be.
The rest of that FAQ goes on to give examples of where UB can be useful for performance reasons, to relieve standard-implementation-tooling from having to try to diagnose (report errors for) ill-formed code that is difficult to diagnose due to the C++ compilation model, and sometimes just due to implementations making use of already standardized UB to perform certain purported optimizations that they are now unwilling to change.
If you're interested in the work that the C++ committee is doing on reducing the number of things it specifies as UB, check out Study Group 12.
Also related: https://en.cppreference.com/w/cpp/language/ub.
You can find some other "useful everyday examples" of UB in C++ at https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#optimizations, including UB from using uninitialized variables (where allowing uninitialized variables is useful for performance), signed integer overflow being UB being useful for certain compiler optimizations, etc.
Sometimes it's done just to reserve space for future changes to the types of code that are labelled UB. Titus Winters has done a talk on this subject, and his paper P0921, which is a user-facing document about "Rights the Standard Library Reserves for Itself" (in the form of certain kinds of UB, mostly to carve out room for itself to change in the future).
#if XXXX #define __future_identifier [[...form compatible with old-compiler, but not necessarily optimal...]] #endif to write code that will benefit from new compiler features if available, but still work on old compilers.
$\endgroup$
The term "Undefined Behavior" is a catch-all used to refer to any of three kinds of situations without trying to distinguish among them:
An implementation is called upon to process a program which, while non-portable, is correct on that platform.
An implementation is called upon to render a program which is erroneous, rendering questions of portability irrelevant.
An implementations is called upon to process a correct and portable program, but the input is erroneous in ways that cannot be reliably meaningfully handled via any standard means (e.g. using "r" mode with fopen to open a file that some other program has written using "wb" mode).
For an implementation to be able to flag an error in response to some erroneous construct, it would need to have some means of determining whether the construct was erroneous rather than correct but non-portable. In many cases, it would be impossible to specify language constructs in a manner that would flag all cases where they were used erroneously, without flagging cases where they were used in correct-but-non-portable fashion to accomplish tasks not provided for by the Standard.
Actively terminating the program may be the worst possible outcome anyway, when the broken run still gives some chances for it to accomplish the mission.
One of the cases would be a rocket controller. If the controller crashes completely, the rocket fails and this is the worst that can happen anyway. Otherwise in some cases a single error may be survivable, like in Ariane V88 crash where it happened in the rocket alignment task no longer important at the given stage of the flight.
Of course, the range of such cases is rather limited. A more typical consumer program would benefit more from printing diagnostics and terminating, making the bugs easier to detect.
Performance is oft-cited as the reason for undefined behavior but this tends to hide the real reason.
Undefined behavior comes from the fact that to specify everything in a programming language would be incredibly infeasible and would also not allow differentiation of implementations.
This is why some things are left undefined in programming language standards rather than them being explicitly spelled out. It both encourages a diversity of implementations that the language can support while letting those that want to target a specific superset do so by opting into certain features at the expense of loss of portability.
Signed integer overflow is a classic example. What do you get when you do
int i = INT_MAX + 1;
It certainly... is C code1, but what does it actually do. Well... it's not defined because there's no portable semantics for such an operation. Depending on the implementation, it may wraparound (as many programmers on two's complement machines expect), it may saturate (as on some DSPs), it may trap, or do any number of things. You could also conceive of an implementation that checked all additions it couldn't prove or aborted translation if it could prove such a thing (at least within some set of assumptions!).
Especially in languages that gained popularity before standardization (such as C (or languages that inherited such concerns from those languages, like C++), many compilers had and have differing ways of expressing certain idioms.
1. There are certainly some who would argue that this isn't C code at all, but it's a view that, for all intents and purposes, is an unnecessarily prescriptivist (and perhaps useless) view of what a C program is, one which is unsupported by the standard itself.