Borland Turbo C 1.5 (Medium --> Large)

Paul S. R. Chisholm psrc at poseidon.ATT.COM
Thu Nov 17 15:33:24 AEST 1988


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

In article <359 at mjbtn.MFEE.TN.US>, root at 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 at mjbtn.MFEE.US.TN

Paul S. R. Chisholm, psrc at poseidon.att.com (formerly psc at 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.



More information about the Comp.lang.c mailing list