Hi Nicolas,
�� thanks for the comment, you are right the problem is the bad
original code. But my opinion is that it just is not reporting the
situation correctly, generating a warning or non-optimizing the code
looks more like a expected behavior. Because as I have said, using a
constant as index in the last statement generates a meaningful warning
and the non-optimizated version of the function.
And again as you said, the only thing to learn about all this is that
we should not write crappy code.
Hang on. ��"crappy code" is too strong.�� Back in tre ANSI days it was not undefined behavior, and in fact I think this only because undefined behavior because C compilers were faced with lots of code where variables were typed int but were being used on 64-bit machines.�� Had the C world used long as its default type then there would have been no need to make casting the address of a long into the address of an int undefined behavior.�� So this isn't crappy code (if you think of what it means in memory on a 64-bit little endnan machine it is perfectly sensible).�� It /is/ code that is inappropriate given C99.
So yes, we have to bow to the C gods and generate C99 compliant code, but what we were doing here wasn't crappy, it was merely code that became undefined behavior so that C compilers could generate more efficient code for 64-bit systems in the presence of code that contains lots of integer variables declared as int.�� So let's just say that we have to generate C99 compliant code.�� You'll notice that the Smalltalk code in the original does exactly what you suggest Pablo.