> i do no understand this discussion about the code fragment > bit =3D ++bit % 8; > 1. Since 20 years, C is my favorite programming language > 2. Since some years, I give classes in C > 3. The code line "bit =3D ++bit % 8", is fully correct.
No. 'bit' is modified twice between sequence points, so the behaviour is undefined. See comp.lang.c FAQ, section 3.1, 3.2, 3.3, 3.3b, and others. (http://www.faqs.org/) Basically, the 'store' part of the pre-increment can happen any time this expression is evaluated. C guarantees that 'bit' will be incremented before the next sequence point and that it uses the incremented value in the rest of the expression, but it does not say that the incremented value gets stored to 'bit' immediately. For example, the compiler can expand the expression to this: tmp1 = bit; # Fetch into register tmp1 = tmp1 + 1; # increment part of ++bit tmp2 = tmp1 % 8; # rest of expression bit = tmp2; # assignment bit = tmp1; # store part of ++bit or it can swap the last two lines (which is the desired result) tmp1 = bit; tmp1 = tmp1 + 1; # increment part of ++bit tmp2 = tmp1 % 8; # rest of expression bit = tmp1; # store part of ++bit bit = tmp2; # assignment or it can even do something like (assuming a register-starved CPU with fast memory-to-memory operations): tmp1 = bit; # Fetch into register tmp1 = tmp1 + 1; # Increment register tmp1 = tmp1 % 8; # rest of expression bit = tmp1; # assignment bit = bit + 1; # increment memory location Depending on the machine architecture, it can even do the increment-store in parallel with the other operations, so you might get a race condition and partial writes from both store operations - or a CPU exception. Anyway, the expression is easily fixed. Either use: ++bit; bit %= 8; or bit = (bit+1) % 8; Regards, Ingo
