C++ Undefined Behavior

[@danielrhouck]

The code at 7:40 is perfectly well-defined since C++11 (or would be, if it compiled; you compare a `char` to a string literal). When you get to the greater-than, it checks `inputStr[index+1] == ':' && inputStr[index+2] == ':'`. The first comparison indexes the string at `inputStr.size()`, which returns a reference to a null character. Then it checks if `'\0' == ':'`, which it does not; this causes short-circuiting and and `inputStr[index+2]` is never called. Pre-C++11, this in UB because indexing at `size()` is UB for a non-`const` string.

[@CopperSpice]

( Commenting for clarity. ) In our conference version of this talk (where we had more time) we explained it was not actually an std::string but rather a string class which did not guarantee null termination. So in the client code we were debugging, it was in fact UB.

[@brettwormley]

it's been a few years and 5k people since this was published. but am i missing something? the code at 7:40 is deeply flawed? shouldn't the condition of the for loop compare against the size of inputStr? and, once found, wouldn't you break out of the loop, since className would have the desired name? and, most importantly, hasn't anyone else caught this in 5 years?

[@CopperSpice]

Yes, you are missing a few things. Please be aware you are not the first person to ask if this is really undefined behavior. The purpose of this code was to find the className which appears after the last "::" so breaking out of the loop earlier does not produce the correct result. In our conference version of this talk (where we had more time) we explained it was not actually an std::string but rather a string class which did not guarantee null termination. So in the client code we were debugging, it was in fact UB. As a side comment, this is one of the reasons we ended up redesigning the string class.

[@brettwormley]

@@CopperSpice thanks for the reply. i'm not disputing the example as UB; rather, the underlying logic (not related to UB). shouldn't the condition of the for loop compare index against the size of inputStr? it compares against the default-initialized className. since index is initialized to 0, and the conditional effectively tests whether 0

[@enesalbay9707]

@@brettwormley you are right. the termination condition must be like that for(int index = 0; i < inputStr.size(); ++index) . It is not a big problem. It is just a mistake.

[@grostig]

Very nice distinction between error and undefined behavior. Also great example about lack of return statement.

[@M4nu3l90F]

10:00 actually comparison of pointers belonging to different blocks/objects is not undefined behavior. It is *unspecified* behavior. It is different in that the implementation is required to return a value and the code cannot be removed. So the comparison must return a value but the standard doesn't say when it must return 'true' or 'false'

[@CopperSpice]

It is true that the behavior in this case is unspecified, but the standard has been very ambiguous in this area and an earlier discussion in the comments for this video resulted in a clarification to the standard. See the comment thread started by Prazek here: kzbin.info/www/bejne/b6qYdaZ3ht12baM&lc=Ugwg5LYhFWpAvBD9XeR4AaABAg and the issue filed against the standard here: github.com/cplusplus/draft/issues/1938

[@M4nu3l90F]

Thanks for the reply. I enjoy your videos!

[@kalucardable]

Based on the C++ standard, undefined behavior is not exclusive to runtime. I know "behavior" may refer to runtime but it's not exclusive to runtime.

[@CopperSpice]

UB can only have an observeable effect at run time. The term behavior is defined as the side effects that the program has while running. Compiling a program either produces an executable or generates an error message. There is no third option of compile time UB.

[@Tchesyo2]

Nice one

[@kumar-ii8cd]

can you make a video on how to setup copperspice on windows

[@CopperSpice]

Can you send us an email letting us know a few more details? We want to make sure we are addressing what you are looking for. Have you seen our CS Overview documentation located on our website? email: info [at] copperspice [dot] com

[@TruthNerds]

Good video, but there is no real notion of a "compile time error" in the standard. The only requirement placed on an implementation upon encountering a violation of a "diagnosable rule" is to issue at least one diagnostic message. It doesn't have to stop producing an executable, and if it does make one, the executable has implicit UB. Also, an implementation is allowed to issue a diagnostic message even when the input is well-formed. Therefore, an implementation that unconditionally prints "NOTE: Frank is stupid" satisfies the letter of this rule. (Certainly not the spirit, though.)