{"id":4708,"date":"2024-04-21T20:29:08","date_gmt":"2024-04-21T18:29:08","guid":{"rendered":"https:\/\/mariusbancila.ro\/blog\/?p=4708"},"modified":"2024-04-21T20:29:11","modified_gmt":"2024-04-21T18:29:11","slug":"erroneous-behaviour-has-entered-the-chat","status":"publish","type":"post","link":"https:\/\/mariusbancila.ro\/blog\/2024\/04\/21\/erroneous-behaviour-has-entered-the-chat\/","title":{"rendered":"Erroneous behaviour has entered the chat"},"content":{"rendered":"\n

The C++ language defines the observable behaviour of a program and uses terms such as ill-formed<\/em> or undefined behaviour<\/em> to describe it. The C++26 standard introduces a new one, called erroneous behaviour<\/em>. In this post, we’ll look at what these terms mean.<\/p>\n\n\n\n

Well-formed<\/h2>\n\n\n\n

This is the simplest of them all. It means that a program is constructed according to the syntactic and semantic rules of the C++ language.<\/p>\n\n\n\n

Ill-formed<\/h2>\n\n\n\n

By contrast, a program that is not well-formed, is called ill-formed. An ill-formed program is a program that has syntactic errors or semantic errors that compilers can diagnose. For such a program, the compiler is required to issue a diagnostic. Here are a couple of examples:<\/p>\n\n\n\n

int main()\n{\n   int a = 42   \/\/ syntax error, missing ;\n}<\/pre>\n\n\n\n
int main()\n{\n   int a = 42;\n\n   auto l = [a](int const a) {return a + 1;};  \/\/ error: lambda capture and lambda parameter have the same name\n}<\/pre>\n\n\n\n
(Trivia: the term ill-formed<\/em> is used about 500 times in the standard.)<\/p>\n\n\n\n
Ill-formed, no diagnostic required<\/h2>\n\n\n\n
This means the program is syntactically correct but has semantic errors, which might not be diagnosable. The compiler is not required to issue a diagnose and executing such a program is undefined behaviour. That doesn’t mean that the compilers do not diagnosticate these problems. In practice, many of these cases do get a diagnose. A couple examples are shown next:<\/p>\n\n\n\n
class foo\n{\n   foo(int a) : foo(a + 1) {} \/\/ constructor delegates to itself\n};<\/pre>\n\n\n\n
float operator \"\"Z(const char*) \/\/ literal suffix identifiers that do not start with an underscore are reserved\n{ return 42; }<\/pre>\n\n\n\n
(Trivia: the term ill-formed, no diagnostic required<\/em> appears about 50 times in the standard.)<\/p>\n\n\n\n
Unspecified behaviour<\/h2>\n\n\n\n
This term defines behaviour that is dependent on the implementation. Examples for such behaviour include the order of function parameter evaluation (which can be from left to right or from right to left) or the amount of memory overhead for an array allocation.<\/p>\n\n\n\n
Implementation-defined behaviour<\/h2>\n\n\n\n
Unspecified behaviour should not be confused with the implementation-defined<\/em> behaviour. The difference between the two is actually small: in the case of implementation-defined behaviour, the effect of the bahaviour must be documented<\/em>, which is not the case for unspecified behaviour.<\/p>\n\n\n\n
Examples of implementation-defined behaviour include the choice of underlying type for the char<\/code> type (which can be either signed char<\/code> or unsigned char<\/code>, although char<\/code> is a distinct type) and the minimum number of buckets for constructing an std::unordered_multiset<\/code> (when a value is not explicitly specified). Often, such implementation-defined choices are described with a comment such as following in the specification:<\/p>\n\n\n\n
unordered_multiset( std::initializer_list<value_type> init,\n                    size_type bucket_count = \/* implementation-defined *\/,\n                    const Hash& hash = Hash(),\n                    const key_equal& equal = key_equal(),\n                    const Allocator& alloc = Allocator() );<\/pre>\n\n\n\n
(Trivia: the term implementation-defined is used 400 times in the standard.)<\/p>\n\n\n\n
Undefined behaviour<\/h2>\n\n\n\n
This is one of the most known traits of the C++ language. For a range of cases that are semantically incorrect, the standard does not impose any restrictions on the behaviour, and does not require the compiler to diagnose the situation (even though compilers do that whenever they can detect such cases). This is called undefined behaviour. A program with undefined behaviour can execute normally, can crash, or can execute without doing anything that is expected without being incorrect. Examples of undefined behaviour include:<\/p>\n\n\n\n