Toughest bug/war stories

This is a discussion on Toughest bug/war stories within the Tech Board forums, part of the Community Boards category; Originally Posted by abachler except that foo[i] is not a single sequence point, but 2 as is foo[i++]. I don't ...

  1. #31
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,264
    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
    Location
    Singapore
    Posts
    22,276
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    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
    Location
    Portugal
    Posts
    7,581
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    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.
    Code:
    //try
    //{
    	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
    Posts
    8,893
    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 OpenOffice.org 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!
    CornedBee

    "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

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21