Xref: utzoo comp.lang.c:14142 comp.sys.ibm.pc:21329
Path: utzoo!attcan!uunet!husc6!rutgers!att!poseidon!psrc
From: psrc@poseidon.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: Borland Turbo C 1.5 (Medium --> Large)
Summary: near/far pointer problems, perhaps
Message-ID: <585@poseidon.ATT.COM>
Date: 17 Nov 88 05:33:24 GMT
References: <359@mjbtn.MFEE.TN.US>
Organization: AT&T Bell Laboratories
Lines: 35

<"He seemed like such a nice man . . . and then he turned out to be a writer!">

In article <359@mjbtn.MFEE.TN.US>, root@mjbtn.MFEE.TN.US (Mark J. Bailey) writes:
> Recently, I was working on a project that had started small and has
> gradually grown to such that the medium memory model on my turbo
> C 1.5 was insufficient to handle it.  I figured that I would just 
> switch to the LARGE model and all would be well.  Well it wasn't.
> When I went to the large model, some fgets statements that loaded
> data into a string pointer that had some memory attached to it by
> a malloc froze up the entire computer when it made the fgets call.
> . . . Would going to HUGE solve my problems or create more?

It would create more.  In the Medium model, near (sixteen bit) pointers
are used for data.  In the Large model, fgets will return a far
(thirty-two bit) pointer.  If you didn't define fgets() (typically by
#include'ing <stdio.h>), it'll be implicitly declared to return an int.
The Large model will try to treat the (thirty-two bit) pointer in the
(sixteen bit) integer, and lose some of the address.

Solutions?  Include <stdio.h> and otherwise make sure you've declared
the functions you use.  (In Turbo C, -wnod or Options/ Compiler/
Errors/ Less Common Errors/ C ["No declaration for function
'XXXXXXXX'"] will tell you when something isn't declared; -wpro or Less
Common Errors/ D ["Call to function with no prototype"] will tell you
when a function is called before it's been fully declared with a
prototype.)

(By the way, if you've got lots of data but not too much code, try the
Compact model instead.)

>Mark J. Bailey, {ames,mit-eddie}!killer!mjbtn!mjb, mjb@mjbtn.MFEE.US.TN

Paul S. R. Chisholm, psrc@poseidon.att.com (formerly psc@lznv.att.com)
AT&T Bell Laboratories, att!poseidon!psrc, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.