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