iLen is a class variable that got updated in Function. On the PPC
iLen would be
updated in time, but on the Intel it wouldn't be. Oddly enough
that same line
of code works fine on my Windows XP port. (in C++ syntax of course)
If you look in the dictionary under "undefined behavior in the C
language" yours is the example that is given. The usual way it is
shown is:
foo(++i, ++i);
The order of evaluation of function parameters is undefined.
The reason for this is efficiency. If the language standard
required any particular order of parameter evaluation then in some
circumstances, on some hardware, that ordering would be less
efficient than another order. The compiler is free to choose the
most efficient order. It has always been this way.
Since the order of parameter evaluation is undefined the compiler
can change this order for any reason. Typically it can change
based on optimization settings. Since the Mac OS X ABI is different
between PPC and Intel it may change between those different
architectures. Obviously it may change between different compilers.
Writing code that depends on undefined behavior is writing buggy code.
The unfortunate thing is that it doesn't generate a warning, because
almost all code does this to a certain degree. Typically the side
effects invoked are mutually independent, but in a complicated
scenario, the compiler cannot tell which side effects will affect the
rest of the function call and which ones will not.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com