X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Tue, 27 Jul 2004 23:11:54 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-Id: <3405-Tue27Jul2004231153+0300-eliz@gnu.org>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <20040727041413.21318.00000463@mb-m18.aol.com> (sterten@aol.com)
Subject: Re: assembly code of the "strange error" - program
References:  <20040727041413 DOT 21318 DOT 00000463 AT mb-m18 DOT aol DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: sterten AT aol DOT com (Sterten)
> Newsgroups: comp.os.msdos.djgpp
> Date: 27 Jul 2004 08:14:13 GMT
> 
> The output is rather ugly, because many instructions require more than line
> and because of the the ATT-assembly-code.

I don't see anything ugly about it.  Perhaps I'm too used to it...

> BTW. why is it used ? Is it easier for the disassembler or for historical
> reasons or ?

Because Unix assemblers use the AT&T style, and GCC was ported from
Unix.

> why is it affected by small changes in the program ?

Because you effectively use a random value as an index into array.
Small changes in the program rearrange the array locations a bit, and
thus the random value becomes valid (i.e., non-negative and small
enough to not exceed the limits of the program's data segment).  But
the program still works incorrectly (produces incorrect results), so
the bug is still there.

>   82:qser3.c       ****     c=C[r];r2=n+1-r;c2=n+1-c;
>  549              		.loc 1 82 0
>  550              	L82:
> GAS LISTING c:/djgpp/tmp/ccKJ0PeS.s 			page 16
> 
> 
>  551 0706 B8200B00 		movl	$_C, %eax
>  551      00
>  552 070b 8B4DC8   		movl	-56(%ebp), %ecx
>  553 070e 8B55C8   		movl	-56(%ebp), %edx
>  554 0711 29F9     		subl	%edi, %ecx
>  555 0713 8B1CB8   		movl	(%eax,%edi,4), %ebx
>  556 0716 41       		incl	%ecx
>  557 0717 29DA     		subl	%ebx, %edx
>   83:qser3.c       ****     R[r]=0;R[r2]=0;R[c]=0;R[c2]=0;
>   84:qser3.c       ****     C[c]=0;C[c2]=0;C[r2]=0;//C[r]=0;

Line 84 is the one that crashes, and it sounds like c's value is bad,
probably because some prior code overwrote the contents of C[r], or
because the value of r is bad (e.g., negative).

So now you know what causes the bug, and you should be able to fix the
program.  The logic should ensure that r never becomes negative, and
that no other index ever goes below zero.