• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 22 subscribers
  • Views 2274 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C Problem?

Jim Leifker 

unsigned char x=1;
x=(x++)<<3;

Using uVision 6.12
Gives answer of 8
It shifts binary 1 left and doesn't increment.
(even when optimization set to level 0)

Using Micorsoft C++ 6.0
Gives answer of 9
It shifts binary 1 left then increments.


I was a little confused with both answers because I was thought that
the increment would happen first because of the ( ) around x++ then
shift left three giving 16 but that's not the case.

This gives me 16 in both Keil and MS.
x=(++x)<<3; works it gives 16


Parents
  • 0

    See "The C Programming Language", second edition, section 2.12. K&R have quite a lot to say about this sort of problem including:

    "One unhappy situation is typified by the statement

    a[i] = i++;
    The question is whether the subscript is the old value of i or the new. Compilers can interpret this in different ways and generate different answers depending up their interpretation...."

Reply
  • 0

    See "The C Programming Language", second edition, section 2.12. K&R have quite a lot to say about this sort of problem including:

    "One unhappy situation is typified by the statement

    a[i] = i++;
    The question is whether the subscript is the old value of i or the new. Compilers can interpret this in different ways and generate different answers depending up their interpretation...."

Children
  • 0 in reply to Graham Cole

    This thread is well and truly dead, but I've found another situation where an ambiguity similar to this can trip you up:

      a[b++] = c;

    The problem is not quite the same as that described above though; it only occurs when multithreading.

    C166 5.00 saves b+1 into b BEFORE assigning c to a[b]. What I found is that an ISR could interrupt this sequence and find b incremented, but the wrong data in a[b] (the assignment hadn't been completed).

  • 0 in reply to Michael Fielding

    Welcome to the wonderful club comprised of those bitten by race conditions. We'll get you your membership card tomorrow.

    In point of fact, there doesn't need to be an index in this expression to cause a problem. Essentially, if you have interrupt-driven code, you must imagine that any instruction that is not "atomic" (i.e. completed without interruption) can be stopped in the middle.

    Thus, something as simple as

    a = b;

    where a and b are 16-bit values and you're using, say, an 8051 can cause problems if they are modified in main code and used in an ISR or vice-versa.

  • 0 in reply to Michael Fielding

    This ambiguity is actually rather unrelated to the one discussed here earlier. The earlier examples had much more serious problems than yours --- they produced undefined behaviour, which means the compiler is allowed to explode the processor 123*pi hours after noon of the Tuesday following last year's Hallowe'en, if it so pleases.

    Your example is broken only because introduced an additional ingredient into the game: multiple (pseudo-)concurrent threads of control. C doesn't even try to address that type of problem in the language itself, beyond controlling access to individual objects via the volatile qualifier.