X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Paul Wilkins <disk AT paradise DOT net DOT nz>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: assembly code of the "strange error" - program
References: <WcpNc.640$zS6 DOT 86489 AT news02 DOT tsnz DOT net> <20040727070949 DOT 29244 DOT 00000306 AT mb-m19 DOT aol DOT com>
In-Reply-To: <20040727070949.29244.00000306@mb-m19.aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 87
Message-ID: <pnxNc.667$zS6.95084@news02.tsnz.net>
Date: Wed, 28 Jul 2004 06:41:49 +1200
NNTP-Posting-Host: 218.101.50.29
X-Complaints-To: abuse AT tsnz DOT net
X-Trace: news02.tsnz.net 1090953813 218.101.50.29 (Wed, 28 Jul 2004 06:43:33 NZST)
NNTP-Posting-Date: Wed, 28 Jul 2004 06:43:33 NZST
Organization: TelstraClear
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Sterten wrote:

> Paul Wilkins wrote:
>  >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.

Please reread what I said. First, areas your are not supposed to access 
(outside array but in programs scope), then areas you are not allowed to 
access,
> 
>  >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

That depends on many factors. This is why you play it safe and go only 
where you are supposed to go.

> So what is written by the compiler into the area directly
> before the data-area ?

Unless you're doing some really fancy futzing with your code, you don't 
need to know that.

>  >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...

If you try to access your arrays beyond their boundries then it'll 
happen all the time. This is a good occasion to stay inside the box.

>  >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 ?

My C manual says otherwise.

     "If you do not initialize any elements of an array, the compiler
      will NOT implicitly set all elements to 0. C does not specify that
      the compiler automatically initialize all variables and arrays. The
      values of an array are undetermined unless you initialize it
      either in the definition statement or by explicit assignment."

There may be a compiler that does initialise them to 0, but you can't 
guarantee that every compiler will do so, so play it safe and work on 
the worst case scenario.

>  >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

If you have to set the initial values to something it's faster than a 
for loop.

>  >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;

And later on when you change the array size and forget to change the 
code you will have nasty problems.

-- 
Paul Wilkins