Loading ...
Sorry, an error occurred while loading the content.

40070Re: Mainly noise

Expand Messages
  • Mike Williams
    Jul 5, 2005
      Bram Moolenaar did utter on 05/07/2005 15:57:

      > I'm glad I don't have to do that job interview :-).
      > Of course it's not clean programming to change a pointer twice, but in
      > rare situations it happens.
      > It's obvious to me that the assignment always happens after evaluating
      > the expression on the RHS.

      Why do you say obvious? By what definition? In C, assignment is no
      different to any other operator in an expression, which is why = is
      called the assigment operator. Assignment is not a statement like in
      BASIC, Pascal, or Python, which is why you can do assignments within if,
      while, etc. expressions. Being an expression, the order of evaluation
      of the left and right hand sides of the assignment operator can be done
      in any order as per any other operator's operands. All that the
      standard specifies is that all side effects are resolved by the next
      sequence point, nothing is said about the order of resolution between
      sequence points.

      > No optimizer should ignore the side effects
      > evaluating the expression might have.

      In C the term "side effect" has a defined meaning, which is essentially
      modification of the execution state, i.e. the values of variables in
      registers and memory. So the simple expression i = 1; contains "side
      effects" due to setting the variable i to the value 1. "Side effects"
      does not mean additional changes to the ones intended as possibly
      understood with the ++/-- operators.

      > Also keep in mind that the "++p"
      > could be in a preprocessor macro and be unnoticable for the programmer
      > (esp. if someone changes the header file after you wrote the code!).

      Indeed, and another typical C interview question where an argument to a
      macro is something like "p++" and the argument appears twice in the body
      of the macro leading to undefined behaviour (the increment may happen
      once or twice). Such macros should be written function like and macro
      args assigned to block local variables to ensure the argument is
      evaluated only once.

      > If the optimizer breaks this I would say the optimizer is broken. If I
      > have to read the details of the C standard to find something isn't
      > guaranteed to work, while the code looks fine to the average programmer,
      > then the C standard is broken, it doesn't do what "should happen".

      The benefit of C's approach is that the optimizer is simpler and
      therefore less bug prone. It is also more flexible across many
      processor architectures providing efficient operation (smaller faster
      binaries). Remember that C is used with more embedded processors than
      PCs where saving bytes and cycles multiplies into big money quickly.

      Some might say that a lot of the issues with copmuters is because
      average programmers don't actually understand the tools they use. And C
      is one of the simpler programming languages out there.

      > Fortunately most compiler builders know this and define the undefined
      > behavior in the way most programmers expect it to work.

      I think you more mean that the few compilers on a couple of processor
      architectures you are aware of happen to work in the way the code was
      intended to work. I haven't seen different compilers for the same
      processor behave differently, but I have seen the issue appear when
      porting to other processors. Don't underestimate the benefit of jobs
      running 10% faster due to optimisations possible from this flexibility in C.

      Ok, this has gone way off topic. Normal service (and lurking) will be
      resumed. ;-)


      The decision is maybe and that's final.
    • Show all 18 messages in this topic