Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!pt!b.gp.cs.cmu.edu!ralf
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: (Still another) Turbo C bug [and another, w/ untested fix]
Message-ID: <70@b.gp.cs.cmu.edu>
Date: Sun, 26-Jul-87 21:34:46 EDT
Article-I.D.: b.70
Posted: Sun Jul 26 21:34:46 1987
Date-Received: Mon, 27-Jul-87 03:44:17 EDT
References: <256@askja.UUCP>
Distribution: world
Organization: Carnegie-Mellon University, CS/RI
Lines: 77
Keywords: Turbo C bug TLINK    startup code
Xref: mnetor comp.sys.ibm.pc:6071 comp.lang.c:3297

In article <256@askja.UUCP> frisk@askja.UUCP (Fridrik Skulason) writes:
>I have found what I believe is a bug in Turbo-C (actually a bug in TLINK -
>I think), namely that the HUGE memory model simply does not work.
...
>But, when linking I got the message
>
> Linker error: Too much global data defined in file
...
>A (very) simplified version of the files in question:
>
>    F.C:
>unsigned char xx[40000];
>main()
>{
>}
>
>    F2.C:
>unsigned char ii[40000];
>
...
>The two large arrays are placed in serparate segments (F_DATA and F2_DATA)
>as they should be, so why do I get the error message from the linker ???
>-- 
>Fridrik Skulason  Univ. of Iceland, Computing Center
>       UUCP  ...mcvax!hafro!askja!frisk                BIX  frisk

I tried this out, and it is indeed a bug in TLINK.  As near as I can tell,
TLINK is not distinguishing between classes and groups.  All segments in the
same class are to be placed consecutively in the .EXE file, whereas all 
segments in the same group are to be placed in a single 64K *physical* segment.

I compiled the two test files to assembler, changed the class of the data
segment for one of the arrays, and then assembled the files.  TLINK handled 
everything correctly.

BTW: MS LINK has no problems whatsoever with the test programs.  Thus, there
are two workarounds for now:  1) link with MS LINK, and 2) compile all 
offending files to assembler and manually change the class names, then 
assemble.
-------------------------------------------------------
There is also a subtle bug in the startup code that will probably only affect
TINY model programs run under an operating environment such as DESQview or
Windows:  if less than 64K is available for the program, it will die while
malloc'ing space for argv[].  The problem is that of the two checks for the
amount of space available, the second sets the amount to allocate incorrectly.

For TINY model, the check is
	if >64K avail, allocate 64K
	else if >abs_min_mem avail, allocate abs_min_mem
where abs_min_mem = code size + global data + 256 bytes (for the stack)
the second allocation should be all available memory.

The fix: (I don't know whether this change to c0.asm will break any of the
other memory models, but I did patch a .COM file with DEBUG and it worked)
	change		
		xchg	bx,di
		cmp	bp,di
		ja	ExcessOfMemory
	to
		mov	di,bp
		cmp	bp,bx
		ja	ExcessOfMemory

[DI contains the amount to allocate, BP contains the amount available, and
BX contains abs_min_mem]

I found this bug because a program which should have happily run in a 13K
DESQview window aborted in anything less than 65K.



	-- 
-=-=-=-=-=-=-=-= {harvard,seismo,ucbvax}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=-
ARPAnet: RALF@B.GP.CS.CMU.EDU            BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA
AT&Tnet: (412) 268-3053 (school)         FIDOnet: Ralf Brown at 129/31
	        DISCLAIMER?  Who ever said I claimed anything? 
"I do not fear computers.  I fear the lack of them..." -- Isaac Asimov