On Thu, 12 Dec 2019 at 04:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Pablo,
On Wed, Dec 11, 2019 at 11:33 AM tesonep@gmail.com <tesonep@gmail.com> wrote:
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.
So maybe interesting to see what happens if C89 is specified... https://renenyffenegger.ch/notes/development/languages/C-C-plus-plus/GCC/opt... Possibly useful sanitizer... https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitiz... cheers -ben