Thread: Toughest bug/war stories

  1. #31
    Registered User
    Join Date
    Sep 2004
    Quote Originally Posted by abachler View Post
    except that foo[i] is not a single sequence point, but 2 as is foo[i++].
    I don't think you know what a sequence point is.
    bit∙hub [bit-huhb] n. A source and destination for information.

  2. #32
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Quote Originally Posted by brewbuck
    Strictly, the behavior is unspecified, not undefined.
    Quote Originally Posted by Mario F.
    I stand corrected.
    Exactly what behaviour are you two talking about? If you are talking about the snippet from post #12, then the behaviour really is undefined, but if you are talking about order of evaluation in general, then the behaviour is unspecified.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #33
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    It's irrelevant abachler.

    What matters is not foo[i++], but i = foo[i++]. The standard defines you are free to swap "sequence points" depending on your needs.

    laserlight: It's in fact order of evaluation in general. That's the context of what brewbuck quoted from me.
    Last edited by Mario F.; 12-29-2009 at 01:24 PM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #34
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Portland, OR
    Quote Originally Posted by Mario F. View Post
    Instead, you can expect a compiler to behave predictably. That's what they do best. What this does not mean however is that one can (or has the ability for that matter) to predict how the compiler will behave.
    The compiler should be deterministic, but it isn't always easy to look at an expression and predict what will happen. For instance, the order in which subexpressions are evaluated may depend on things like register pressure, which you really can't discern. Changing some seemingly unrelated code on a previous or subsequent line may change the evaluation of an intervening expression, simply because the allocation of registers has changed.
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);

  5. #35
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Quote Originally Posted by Mario F. View Post
    Undefined behavior is always clearly defined by the implementation (the combination of compiler and CPU). The same code will always compile to the exact same machine code. There's nothing undefinable about compilers.
    It's true that non-determinism in compilers is usually treated as a bug. Nevertheless, it happens, e.g. in LLVM/Clang we've had several bugs where some data structure (a hash or tree, usually) was sorted according to pointer values - and was thus extremely prone to change in face of the slightest change in the input. In the most recent incarnation, for example, this would change the order in which some functions were emitted in the object file. This can actually make a difference in, say, application startup performance, as the and Mozilla projects have discovered.

    The other issue with undefined behavior is that optimizers tend to treat it in unpredictable ways. The effect? Internal state of the optimizer can completely change the way a statement is treated, i.e. completely unrelated code changes (in a different function, a different module even if using LTO) can change the way the statement is compiled.

    Finally, undefined behavior in the C++0x execution model can be completely undefined: C++0x specifies multiple threads, and thus clearly defines what a race condition is. Programs containing race conditions are undefined, and have fun trying to duplicate the environment closely enough to get guaranteed identical runs from such programs.
    All the buzzt!

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Name Stories
    By sean in forum A Brief History of
    Replies: 55
    Last Post: 11-22-2004, 04:02 AM
  2. toughest math course
    By axon in forum A Brief History of
    Replies: 12
    Last Post: 10-28-2003, 10:06 PM
  3. Drug stories
    By Zewu in forum A Brief History of
    Replies: 1
    Last Post: 07-30-2003, 08:12 AM
  4. Drinking stories
    By Govtcheez in forum A Brief History of
    Replies: 24
    Last Post: 07-30-2003, 07:24 AM
  5. I love ghost stories
    By Nutshell in forum A Brief History of
    Replies: 7
    Last Post: 07-04-2003, 01:57 AM