Re: [ECOS] Optimizations and bad code

[Gary Thomas <gthomas at redhat dot com>]

On 23-Jul-2001 rob.wj.jansen@philips.com wrote:
> 
> Compiler optimizations can be a real pain, especially if you have some funny code.
> Look at the following example:
> 
> {
>     int i, y;
> 
>    i = 0;
> 
>     for(y=0; y<176; y++)
>     {
>         func(x, y, (a[i++] + (a[i++]<<1) + a[i++])>>2);
>     }
> }
> 
> This is real ugly code, extracted from a non working progam.
> It was meant to combine three values from an RGB buffer (containing a 24 bit image)
> into one 8 bit gray scale value. This was no serious programming but just a fast hack
> to get something on the LCD.
> 
> According to the C standard, the arguments to the + operator may be evaluated in any
> order, making it unpredictable to tell if the R, G or B value will get the <<1. But I guess that
> the "i" should always be three more that it started of with after going through the loop once.
> 
> The amizing part however is that with the arm-elf-gcc compiler, it depends if optimizations
> are on "-O2" or off "-O0". Without optimizations i is incremented with 1 (!) after going through
> the loop once. All other variants (including different optimization settings for the
> i686-pc-linux-gnu
> and native linux compiler) have i incremented by 3.
> 
> Although I admit that one should never write code like this, the results are amazing.
> It just shows that "working in my private enviroment" does not mean it is correct code.

This code is simply frightening!!

Firstly, in the line
         func(x, y, (a[i++] + (a[i++]<<1) + a[i++])>>2);
the order of the i++ is not guaranteed at all, so the results could vary
widely from platform/architecture to platform.

Also, since the value of 'i' is not used after the for{} loop, or even within it except
as an index, there is no reason at all for the compiler to ever keep it around or make
the updated value available.

The worst part of it all is that even "This was no serious programming but just a fast hack",
writing this sort of code can become habitual.  Once in that "mold", the programmer will
write similar code for "serious" use and then wonder why it doesn't work :-(