Thread: i=++i; operation undefined?

Originally Posted by password636

Then why does compiler still report 'operation on i may be undefined'? Only because it has two side effects?

As you noted, the code does not conform to the requirements laid down in the C standard. Besides, I'd say that it is a Good Thing for the compiler to complain, considering that a simple ++i; was all that was intended, so the point is moot anyway.

Technically why wouldn't it 1) get the value of ++i, 2) assign result to i, 3) apply side-effect of increment?

It is also somewhat simpler to express your idea with simply ++i;

Originally Posted by password636

I'm sorry but is this possible? I think the side effect of increment is the "INC" directive in assembly, and as the C requires: "INC" should take place before its value is noted. Then why 1) does ++i while 3) still does it again?

The reason the specification is such as it is, is that it allows compilers to be "clever" about what instruction it uses - not all processors have a specific "inc" instruction - in fact MANY processors don't: 29k, 68k, arm, VAX at least do not have a specific instruction called "inc" - they obviously have other instructions that will do that work (e.g. add with constant 1).

--
Mats

Originally Posted by password636

Yes. The compiler reports what doesn't conform to the C standard. I thought if the C standard didn't define the order, there must be more than one order technically, depending on the compilers. But with this example, I can't find another order. So "undefined by the C standard" doesn't mean "more than one order" definitely exists. It's just "undefined". If this is right, I'd say what I thought was wrong.

I think you are right in the sense that there is no "alternatives" in this particular case. The case in the standard that covers this particular example ALSO covers i++ + i++, in which case there are definitely more than one alternative interpretation.

--
Mats

Originally Posted by matsp

I think you are right in the sense that there is no "alternatives" in this particular case. The case in the standard that covers this particular example ALSO covers i++ + i++, in which case there are definitely more than one alternative interpretation.

On processors that don't have "inc" you mentioned above, I wonder if there may be a possibility like this:
1. Move i's value to a register and add 1 to the register
2. Use the value in the register to assign i <-- side effect
3. add 1 to i <-- side effect

This seems a little stupid. But this sequence can have another order: 1, 3, 2. And thus operations on i undefined. So do the prefix ++ in C guarantee the subsequent operations use the value stored in i or the value obtained through a temporary place, like a register? I mean increment operators definitely will increment the object at the end. But the value used in subsequent operations comes from the object itself or another place where holds [its value + 1]? I think the C language does not define this, it's so machine-related. Besides, the sequence is like anon's.

I still think it's more a case of "this is undefined in the same set as many other things", and the REASON the "many things" are undefined is to allow the compiler to do clever things and not have to worry about "what if the expression is x = i++ + ++i?". This expression, that could probably be defined would just end up being a exception case of "all of these are undefind except when you do i = ++i;" - and the benefit of having exceptions like that would be?

--
Mats

Originally Posted by matsp

and the benefit of having exceptions like that would be?

More developers employed to help write the compiler?

Originally Posted by MK27

More developers employed to help write the compiler?

No, it would only take someone clever about 15 minutes to add an exception to the "give warnings for undefined stuff" - it's not like the compiler doesn't actually DO anything for these undefined things - it's just not guaranteed to do anything like what you may consider "the right thing" [whatever that may be].

--
Mats