Mail Archives: djgpp/2004/07/27/07:15:10
Paul Wilkins wrote:
>R[r] is looping with the r index being reduced by one each time, so the
>program is accessing R[3], R[2], R[1], R[0], and then on to R[-1],
>R[-2], etc..
yes
>Most people will now be feeling a sense of horror, at seeing negative
>array indexes, because arrays ARE NOT supposed to have negative indicies.
and that should be reason enough for a good compiler to issue a runtime
warning at this point. The reason why gcc doesn't do this is mere
program-speed, I assume. But this warning/error suppressing
could also be put into one of the optimising switches "-Ox" IMO.
>The following is a quote from a C manual that I currently have to hand.
>
> "One of the most coimmon and troublesome errors in C programming
> occurs when an index value goes out of range for an array - that
> is, when an index value is less than zero or greater than the size
> of the array minus one."
if it's such a common error, then why is there apparantly no utility yet
to convert .c sources into other .c sources which test the array bounds ?
Can't be so difficult to write such a program.
>To get back to your question, what is going wrong is that R[r] is trying
>to access negative indicies (the r value). At first C lets you do that
>even though you're not supposed to, because C give you enough rope with
>which to hang yourself.
3rd time in a few days that I hear this ;-)
C gives me enough rope to hang myself _by accident_ .I'd wish it were
safer to use C.
>As r gets lower and lower you are moving from memory areas that you are
>not supposed to access, to memory areas that you are not ALLOWED to
>access (the General Protection Fault), which is why the crash occurs.
no.Not yet. It crashes later, when it reads from these areas and uses these
data to calculate and access some really distant,unallowed addresses.
This makes debugging even harder.
>Why your program sometimes crashes with one compile time option and not
>wqith other options,
or even when I change one letter in an unused variable name !
>is because the part that is crashing is walking
>backwards through memory looking for a "1" value. Some compiled versions
>may have that somewhere in the unused parts of data block, and some may
>not have it.
how far am I allowed to go back, before gcc will crash ?
I tried : int main(){i=9;m1:printf("%i ",i);c=R[i];i++;goto m1;}
i goes up to about 150000 and down to about -12000 before it crashes
So what is written by the compiler into the area directly
before the data-area ?
>My question for you is, where to from here. Are you wanting to fix this
>so that it just doesn't happen, or are you wanting to delve a lot deeper
>into assembly language.
understand, how likely such errors will occur in future.
Also I was a bit urged by Eli to investigate this deeply...
>Trivia: When defining arrays the contents are determined in different ways.
>
>int R[99]; // won't be initialised and will have different values
I was told, they were set to zero ?
>int S[99]={1}; // S[0]==1, S[1] to S[98] are set to 0.
>int T[99]={1,2,3}; // sets T[0]==1, T[1]==2, T[2]==3, others are 0.
which has the disadvantage that compiled programs are much larger
>Now check this out.
>
>int U[99]; memset(U, 4, sizeof(U));
>
>memset fills the memory locations used by U with the value 4.
I prefer: for(i=0;i<99;i++)U[i]=4;
--Guenter.
- Raw text -