Re: [ILUG] gcc optimisation weirdness?

From: Caolan McNamara (cmc at domain stardivision.de)
Date: Wed 10 May 2000 - 18:34:57 IST


>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10.05.00, 18:38:44, Paul Jakma <paulj at domain 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.



This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:06:06 GMT