[comp.sys.ibm.pc] Bug in Turbo-C ver 2.0

mk@vall.dsv.su.se (Magnus Karlson) (08/10/89)

I were able to isolate the bug i hade located in TURBO-C ver 2.0
when using HUGE memory model. Since several people asked for the
information i thought i also hsould post it here.

The following C file will generate incorect code for the last
line in the procedure "headline", the work around is simple
define a local variabel and set it to M1size[choise] before
the procedure call and use the local variabel in the last line
instead. But it is not simple all possible places this work around
must be inserted...

Here is the C file:
#include <stdio.h>

extern char hdl_txt[], *M1text[];
extern int   M1size[];
extern char ChrAttr;
extern char HeadAttr;

char tmpattr;

tmp_attr()
{
   tmpattr = ChrAttr;
}

chr_attr()
{
    ChrAttr = tmpattr;
}

headline(choice)		/* Makes a headline */
int choice;
{
    tmp_attr();
    ChrAttr = HeadAttr;
    clear(0, 0, 0, 79);				/* Clear first row  */
    chr_attr();
    outsna(0, 1, hdl_txt);
    outsna(0, 79-M1size[choice], M1text[choice]);
}

this will generate the following striped down assembler file:

_headline	proc	far
		.
		.
		.
	call	far ptr _outsna
	add	sp,8
;	?debug	L 32
	mov	bx,word ptr [bp+6]
	shl	bx,1
	shl	bx,1
	mov	ax,seg _M1text
	mov	es,ax
	push	word ptr es:_M1text[bx+2]
	push	word ptr es:_M1text[bx]
	mov	bx,word ptr [bp+6]
	shl	bx,1
	mov	ax,seg _M1size
	mov	es,ax
	mov	ax,79
	mov	dx,seg _M1size			;Shouldn't be there
	push	bx				;Shouldn't be there
	mov	es,dx				;Shouldn't be there
	mov	dx,word ptr es:_M1size		;Should be .. _M1size[bx]
	sub	ax,dx
	push	ax
	xor	ax,ax
	push	ax
	call	far ptr _outsna
	add	sp,8
@3:
;	?debug	L 33
	pop	ds
	pop	bp
	ret	
_headline	endp


Even more iretating is that we don't actualy need HUGE model for this
project if there existed a compiler switch like the MicroSoft C "/Gt<num>"!

	Magnus Karlson

heimir@rhi.hi.is (Heimir Thor Sverrisson) (08/11/89)

mk@vall.dsv.su.se (Magnus Karlson) writes:

>I were able to isolate the bug i hade located in TURBO-C ver 2.0
>when using HUGE memory model. Since several people asked for the
>information i thought i also hsould post it here.

I found this same bug several months ago. My experience was that it
showed up _only_ when using the HUGE memory model _and_ subtracting
and 'extern'ally defined array element. The following code would crash:

extern int i_arr[];

main()
{
    int i,j;

    j = i - i_arr[0];
}

While addition was OK. Therefore my workaround was:

extern int i_arr[];

main()
{
    int i,j;

    j = i + (-i_arr[0]);
}

The code generated for the substraction actually destroys the stack, so
you will certainly see it on your program :-)

I sent a full documentation of the bug to the local Borland dealer, but
that was just as sending it to the null-device :-(
--
Heimir Sverrisson
NeuroSoft Inc.