5 ms·

Most languages have Undefined and Implementation specific behavior. Few languages have so carefully specified their undefined behavior as C++ though.

• seanwilson 10y ago
  Any examples? My experience is you will frequently be bitten by undefined behaviour in C++ if you don't know the rules well but this is very rare in other languages. It's rare you're going to get a segfault or the whole program crashing in languages like Python, Java and JavaScript.
  • firethief 10y ago
    Those languages all have heavy runtime environments; if a segfault occurs it's an interpreter bug. Whether the mistakes you can make are a result of "undefined behavior" is a different question whether from the consequences of a mistake are an abrupt termination, or an abrupt termination with a helpful error message.
    • sqeaky 10y ago
      This is how it works in Ruby. In the CRuby/MRI interpretter when a segfault happens it calls the #to_s method on the current execution context, to get the some memory address and technical details. Ruby happens to be flexible enough that you can override that method. Then you can call whatever you want and you have effectly "recovered" from a segfault. The parser is totally in an inconsistent state and could crash at any moment for any reason but it works often enough people have done it live in front of audiences for talks. It is not officially specified that I am aware of that overloading #to_s on anything allows recovering of segfaults it is intended for converting things to_strings. For more on what I mean start reading the Ruby standard, which was about 1,500 pages last I checked. Then check the C++ standard which is about 3,000 for C++11 and then another 2,500 for the standard library. C++ with its standard library is much smaller than Ruby (in terms of the functionality provided) but has at least 3 times the specificity.
      • blub 10y ago
        Interesting post. Small comment: the C++11 standard has about 1300 pages, not 5500, thank goodness.
        • sqeaky 10y ago
          I misremembered... So I just went and look this up the C++14 standard, or at least the nNvember draft is 1368 pages and the Ruby ISO standard is 313. I was off by a fair amount. But this made my point more extreme. C++ has mauch smaller feature list than Ruby and the spec is more 4x the size C++ is much more specific and precise. Ruby and many other languages will use the behavior of some de-facto implementation as their standard.
          • lmm 10y ago
            Is C++ really better specified? Some languages use "the implementation is the spec" and that's bad, sure (though I'd argue it's less bad than "programs that worked on previous versions of the compiler will contain memory safety vulnerabilities on newer versions of the compiler", which is the end result of C++'s approach to undefined behaviour). But compare to e.g. Java, which has a (shorter!) spec with multiple implementations, including a well-specified memory model in the presence of threads (which weren't even specified at all by C++ until recently), and more importantly actually defines behaviour rather than specifying very carefully the wide range of conditions in which the compiler is permitted to arbitrarily break your code.
            • sqeaky 10y ago
              Memory is specifically hard one for C++ because it tries not to put a layer between the coder and the underlying hardware. Much of the memory model must be implementation defined. It wasn't that long ago that we had different pointer for small fast memory and large slow memory, back when more that 64k was a real big deal. Kind of like how now video memory is a real big deal. Now we have a bunch of weird C APIs for putting things there (I presume these can be accessed from JNI or something similar), but these are temporary ugly hacks. When video ram becomes a more common thing to refer to specifically, what will that look like in Java? That weird memory that C++ has is ready, because it has done exactly this in the past a few times. I am also looking forward to C++17 and its newer way to run std algorithms on heterogeneous executors (like GPUs).
• kazinator 10y ago
  Undefined behavior is not specified, by definition! It is the absence of requirements, including the requirements to diagnose. C++ has something called "unspecified behavior" also, which is stronger than undefined, because it gives requirements. It denotes some circumstances when an implementation can behave in one of a finite possible ways (none of which fail) and must choose one of them without documenting which choice is made. For instance the expression f(a(), b(), c()) can call the functions a, b and c in any of the six possible permutations of the order: no particular order is specified. (This arises due to the order of evaluation of function arguments being unspecified, together with the sequenced evaluation of function calls.) The specifications of C and C++ contain large number of places in which they carefully state that no requirements apply to some situation. This is not a good thing; it's basically a myriad holes punched in the requirement spec, any one of which could be a pitfall. Few languages are so chock full of holes in their requirements.
  • paulddraper 10y ago
    > Undefined behavior is not specified > unspecified is stronger than undefined because it gives requirements. I do not understand what you are saying.
    • kazinator 10y ago
      "unspecified behavior" in C++ is a formal term denoting a situation in which requirements are in fact given. There are multiple possible requirements, and the implementation chooses which apply, without having to document the choice. So in fact something is specified, just not entirely. "undefined behavior" refers to situations in which no requirements apply at all. (Truly unspecified in the regular sense of the word.)
      • paulddraper 10y ago
        Thanks, I understand your usage now. Unspecified means the implementation has some leeway. Undefined means the implementation can do anything.