Why does C++ have 'undefined behaviour' (UB) and other languages like C# or Java don't?

Question

This Stack Overflow post lists a fairly comprehensive list of situations where the C/C++ language specification declares as to be 'undefined behaviour'. However, I want to understand why other modern languages, like C# or Java, doesn't have the concept of 'undefined behavior'. Does it mean, the compiler designer can control all possible scenarios (C# and Java) or not (C and C++)?

Answer 1

Basically because the designers of Java and similar languages didn't want undefined behavior in their language. This was a trade off - allowing undefined behavior has the potential to improve performance, but the language designers prioritized safety and predictability higher.

For example, if you allocate an array in C, the data is unspecified. In Java, all bytes must be initialized to 0 (or some other specified value). This means the runtime must pass over the array (an O(n) operation), while C can perform the allocation in an instant. So C will always be faster for such operations.

If the code using the array is going to populate it anyway before reading, this is basically wasted effort for Java. But in the case where the code read first, you get predictable results in Java but unpredictable results in C.

Answer 2

Undefined behaviour is one of those things that were recognized as a very bad idea only in retrospect.

The first compilers were great achievements and jubilantly welcomed improvements over the alternative - machine language or assembly language programming. The problems with that were well-known, and high-level languages were invented specifically to solve those known problems. (The enthusiasm at the time was so great that HLLs were somtimes hailed as "the end of programming" - as if from now on we would only have to trivially write down what we wanted and the compiler would do all the real work.)

It wasn't until later that we realized the newer problems that came with the newer approach. Being remote from the actual machine that code runs on means there is more possibility of things silently not doing what we expected them to do. For instance, allocating a variable would typically leave the initial value undefined; this wasn't considered a problem, because you wouldn't allocate a variable if you didn't want to hold a value in it, right? Surely it wasn't too much to expect that professional programmers wouldn't forget to assign the initial value, was it?

It turned out that with the larger code bases and more complicated structures that became possible with more powerful programming systems, yes, many programmers would indeed commit such oversights from time to time, and the resulting undefined behaviour became a major problem. Even today, the majority of security leaks from tiny to horrible are the result of undefined behaviour in one form or another. (The reason is that usually, undefined behaviour is in fact very much defined by things on the next lower level on computing, and attackers who understand that level can use that wiggle room to make a program do not only unintended things, but exactly the things they intend.)

Since we recognised this, there has been a general drive to banish undefined behaviour from high-level languages, and Java was particularly thorough about this (which was comparatively easy since it was designed to run on its own specifically designed virtual machine anyway). Older languages like C can't easily be retrofitted like that without losing compatibility with the huge amount of existing code.

Edit: As pointed out, efficiency is another reason. Undefined behaviour means that compiler writers have a lot of leeway for exploiting the target architecture so that each implementation gets away with the fastest possible implementation of each feature. This was more important on yesterday's underpowered machines than with today, when programmer salary is often the bottleneck for software development.

Answer 3

Undefined behavior enables significant optimization, by giving the compiler latitude to do something odd or unexpected (or even normal) at certain boundary or other conditions.

See http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Use of an uninitialized variable: This is commonly known as source of problems in C programs and there are many tools to catch these: from compiler warnings to static and dynamic analyzers. This improves performance by not requiring that all variables be zero initialized when they come into scope (as Java does). For most scalar variables, this would cause little overhead, but stack arrays and malloc'd memory would incur a memset of the storage, which could be quite costly, particularly since the storage is usually completely overwritten.

---

Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X". While these may seem trivial, these sorts of things are commonly exposed by inlining and macro expansion. A more important optimization that this allows is for "<=" loops like this:

for (i = 0; i <= N; ++i) { ... }

In this loop, the compiler can assume that the loop will iterate exactly N+1 times if "i" is undefined on overflow, which allows a broad range of loop optimizations to kick in. On the other hand, if the variable is defined to wrap around on overflow, then the compiler must assume that the loop is possibly infinite (which happens if N is INT_MAX) - which then disables these important loop optimizations. This particularly affects 64-bit platforms since so much code uses "int" as induction variables.

Answer 4

In C's early days, there was a lot of chaos. Different compilers treated the language differently. When there was interest to write a specification for the language, that specification would need to be fairly backwards-compatible with the C that programmers were relying on with their compilers. But some of those details are non-portable and do not make sense in general, for example assuming a particular endianess or data layout. The C standard therefore reserves a lot of details as undefined or implementation-specified behaviour, which leaves a lot of flexibility to compiler writers. C++ builds upon C and also features undefined behaviour.

Java tried to be a much safer and much simpler language than C++. Java defines the language semantics in terms of a thorough virtual machine. This leaves little space for undefined behaviour, on the other hand it makes requirements that can be difficult for a Java implementation to do (e.g. that reference assignments must be atomic, or how integers work). Where Java supports potentially unsafe operations, they are usually checked by the virtual machine at runtime (for example, some casts).

Answer 5

JVM and .NET languages have it easy:

1. They don't have to be able to work directly with hardware.
2. They only have to work with modern desktop and server systems or reasonably similar devices, or at least devices designed for them.
3. They can impose garbage-collection for all memory, and forced initialization, thus getting pointer-safety.
4. They got specified by a single actor who also provided the single definitive implementation.
5. They get to choose safety over performance.

There are good points for the choices though:

1. Systems programming is a whole different ballgame, and uncompromisingly optimising for application programming instead is reasonable.
2. Admittedly, there is less exotic hardware all the time, but small embedded systems are here to stay.
3. GC is ill-suited for non-fungible resources, and trades much more space for good performance. And most (but not nearly all) forced initializations can be optimized away.
4. There are advantages to more competition, but committees mean compromise.
5. All those bounds-checks do add up, even though most can be optimized away. Null pointer checks can mostly be done by trapping access for zero overhead thanks to virtual address space, though optimisation is still inhibited.

Where escape-hatches are provided, those invite full-blown undefined behavior back in. But at least they are generally only used in few very short stretches, which are thus easier to manually verify.

Answer 6

First a quick aside: for the purposes of this answer, I'm going to lump "undefined behavior" and "implementation defined behavior" together as all being "undefined behavior". The primary difference between the two is that an implementation needs to document implementation defined behavior. At least to me this seems like a small enough difference that it doesn't matter much.

The real reason comes down to a fundamental difference in intent between C and C++ on one hand, and Java and C# (for only a couple of examples) on the other. For historical reasons, much of the discussion here talks about C rather than C++, but (as you probably already know) C++ is a fairly direct descendant of C, so what it says about C applies equally to C++.

Although they're largely forgotten (and their existence sometimes even denied), the very first versions of UNIX were written in assembly language. Much of (if not solely) the original purpose of C was port UNIX from assembly language to a higher level language. Part of the intent was to write as much of the operating system as possible in a higher level language--or looking at it from the other direction, to minimize the amount that had to be written in assembly language.

To accomplish that, C needed to provide nearly the same level of access to the hardware as assembly language did. One of the stated goals of C++ has always been that it should continue to provide the same low-level access to hardware as C does.

The PDP-11 (for one example) mapped I/O registers to specific addresses. For example, you'd read one memory location to check whether a key had been pressed on the system console. One bit was set in that location when there was data waiting to be read. You'd then read a byte from another specified location to retrieve the ASCII code of the key that had been pressed.

Likewise, if you wanted to print some data, you'd check another specified location, and when the output device was ready, you'd write your data yet another specified location.

To support writing drivers for such devices, C allowed you to specify an arbitrary location using some integer type, convert it to a pointer, and read or write that location in memory.

Of course, this has a pretty serious problem: not every machine on earth has its memory laid out identically to a PDP-11 from the early 1970's. So, when you take that integer, convert it to a pointer, and then read or write via that pointer, nobody can provide any reasonable guarantee about what you're going to get. Just for an obvious example, reading and writing may map to separate registers in the hardware, so (contrary to normal memory) if you write something, then try to read it back, what you read may not match what you wrote.

I can see a few possibilities that leaves:

1. Define an interface to all possible hardware--specify the absolute addresses of all the locations you might want to read or write to interact with hardware in any way.
2. Prohibit that level of access, and decree that anybody who wants to do such things needs to use assembly language.
3. Allow people to do that, but leave it up to them to read (for example) the manuals for the hardware they're targeting, and write the code to fit the hardware they're using.

Of these, 1 seems sufficiently preposterous that it's hardly worth further discussion. 2 is basically throwing away the basic intent of the language. That leaves the third option as essentially the only one they could reasonable consider at all.

Another point that comes up fairly frequently is the sizes of integer types. C takes the "position" that int should be the natural size suggested by the architecture. So, if I'm programming a 32-bit VAX, int should probably be 32 bits, but if I'm programming a 36-bit Univac, int should probably be 36 bits (and so on). It's probably not reasonable (and might not even be possible) to write an operating system for a 36-bit computer using only types that are guaranteed to be multiples of 8 bits in size. Maybe I'm just being superficial, but it seems to me that if I were writing an OS for a 36-bit machine, I'd probably want to use a language that supported a 36-bit type.

From a language viewpoint, this leads to still more undefined behavior. If I take the largest value that will fit into 32 bits, what will happen when I add 1? On typical 32-bit hardware, it's going to roll over (or possibly throw some sort of hardware fault). On the other hand, if it's running on 36-bit hardware, it'll just...add one. If the language is going to support writing operating systems, you can't guarantee either behavior--you just about have to allow both the sizes of types and the behavior of overflow to vary from one to another.

Java and C# can ignore all of that. They aren't intended to support writing operating systems. With them, you have a couple of choices. One is to make the hardware support what they demand--since they demand types that are 8, 16, 32 and 64 bits, just build hardware that supports those sizes. The other obvious possibility is for the language to only run on top of other software that provides the environment they want, regardless of what the underlying hardware might want.

In most cases, this isn't really an either/or choice. Rather, many implementations do a little of both. You normally run Java on a JVM running on an operating system. More often than not, the OS is written in C, and the JVM in C++. If the JVM is running on an ARM CPU, chances are pretty good that the CPU includes ARM's Jazelle extensions, to tailor the hardware more closely to Java's needs, so less needs to be done in software, and the Java code runs faster (or less slowly, anyway).

Summary

C and C++ have undefined behavior, because nobody's defined an acceptable alternative that allows them to do what they're intended to do. C# and Java take a different approach, but that approach fits poorly (if at all) with the goals of C and C++. In particular, neither seems to provide a reasonable way to write system software (such as an operating system) on most arbitrarily chosen hardware. Both typically depend on facilities provided by existing system software (usually written in C or C++) to do their jobs.

Answer 7

Java and C# are characterized by a dominant vendor, at least early in their development. (Sun and Microsoft respectively). C and C++ are different; they've had multiple competing implementations from early on. C especially ran on exotic hardware platforms, too. As a result, there was variation between implementations. The ISO committees that standardized C and C++ could agree on a large common denominator, but at the edges where implementations differ the standards left room for the implementation.

This is also because choosing one behavior might be expensive on hardware architectures that are biased towards another choice - endianness is the obvious choice.

Answer 8

The authors of the C Standard expected their readers to recognize something they thought was obvious, and alluded to in their the published Rationale, but didn't say outright: the Committee shouldn't need to order compiler writers to meet their customers' needs, since the customers should know better than the Committee what their needs are. If it's obvious that compilers for certain kinds of plaforms are expected to process a construct a certain way, nobody should care whether the Standard says that construct invokes Undefined Behavior. The Standard's failure to mandate that conforming compilers process a piece of code usefully in no way implies that programmers should be willing to buy compilers that don't.

This approach to language design works very well in a world where compiler writers need to sell their wares to paying customers. It completely falls apart in a world where compiler writers are isolated from the effects of the marketplace. It's doubtful the proper market conditions will ever exist to steer a language the way they had steered the one that became popular in the 1990s, and even more doubtful that any sane language designer would want to rely upon such market conditions.

Answer 9

C++ and c both have descriptive standards (the ISO versions, anyway).

Which only exist to explain how the languages work, and to provide a single reference about what the language is. Typically, compiler vendors, and library writers, lead the way and some suggestions get included in the main ISO standard.

Java and C# (or Visual C#, which I assume you mean) have prescriptive standards. They tell you what's in the language definitively ahead of time, how it works, and what's considered permitted behavior.

More important than that, Java actually has a "reference implementation" in Open-JDK. (I think Roslyn counts as the Visual C# reference implementation, but couldn't find a source for that.)

In Java's case, if there's any ambiguity in the standard, and Open-JDK does it a certain way. The way Open-JDK does it is the standard.

Answer 10

Undefined behaviour allows the compiler to generate very efficient code on a variety of architecturs. Erik's answer mentions optimization, but it goes beyond that.

For example, signed overflows are undefined behaviour in C. In practice the compiler was expected to generate a simple signed addition opcode for the CPU to execute, and the behaviour would be whatever that particular CPU did.

That allowed C to perform very well and produce very compact code on most architectures. If the standard had specified that signed integers had to overflow in a certain way then CPUs which behaved differently would have needed a lot more code generating for a simple signed addition.

That's the reason for much of the undefined behaviour in C, and why things like the size of int vary between systems. Int is architecture dependent and generally selected to be the fastest, most efficient data type that is larger than a char.

Back when C was new these considerations were important. Computers were less powerful, often having limited processing speed and memory. C was used where performance really mattered, and developers were expected to understand how computers worked well enough to know what these undefined behaviours would actually be on their particular systems.

Later languages such as Java and C# preferred eliminating undefined behaviour over raw performance.

Answer 11

In a sense, Java also have it. Suppose, you gave incorrect comparator to Arrays.sort. It can throw exception of it detects it. Otherwise it will sort an array in some way that is not guaranteed to be any particular.

Similarly if you modify variable from several threads results are also unpredictable.

C++ is just went further to make undefined more situations(or rather java decided to define more operations) and to have a name for it.