[ILUG] gcc optimisation weirdness?

[Caolan McNamara]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10.05.00, 18:38:44, Paul Jakma <paulj at itg.ie> wrote regarding [ILUG] gcc 
optimisation weirdness?:

> gcc seems to do weird things to the following:
> int input, frequency[9];

int input, frequency[10];

you accept a value of 10 for input, you would then index into frequency 
at position frequency[9] unfortunately this is the 10th element and 
frequency is 9 long. Once you go into out of bounds territory then 
anything can happen. 

The other comment about the statement 
(f[i])++;
being invalid is just wrong, thats perfectly legal. Nothing to do with 
compound statements, the brackets are in their guise of simple precedence 
here, the gcc extension would only go into effect if the bracketed 
components do not break down to yield a single lvalue

> PS: is there anyway to initialise an array at declaration time, rather
> than iterate thru the array and set each element manually? eg something
> like: int array[9]=0;

int array[9]={0};
explicitly sets array[0] to 0 , and as an aggregate the remaining 
elements are implicitly set to 0. 
http://www.eskimo.com/~scs/cclass/notes/sx4aa.html
There is the ugly 
memset(array, 0, 9);
but its unnecessary. (and there is an obscure argument about memset 
setting a 0 bitpattern vs 0 being a logical 0 but thats an unnecessary 
bit of fluff that we can go into another day)

Setting all chars to a non 0 value forces you back to an explicit listing 
int a[3] = {1, 1, 1}; or back to a memset.

C.