dkchen@uicsrd.csrd.uiuc.edu (03/22/90)
Hi, netters: Recently I tried to port my program from an unix machine to my 386/20 running turbo/c. To my surprise, turbo/c sometimes returned ds:0000 from the malloc routine. Consecutive malloc will not solve this problem. I assume ds:0000 should be reserved as 'nil'. And printing data pointed by pointer with value ds:0000 actually generate (null) as output. Am I missing anything (such as compiler switches, etc.)? The turbo/c I used is version 2.0. All comment are appreciated. Dean
scjones@sdrc.UUCP (Larry Jones) (03/24/90)
In article <42900071@uicsrd.csrd.uiuc.edu>, dkchen@uicsrd.csrd.uiuc.edu writes: > Recently I tried to port my program from an unix machine to my 386/20 > running turbo/c. To my surprise, turbo/c sometimes returned ds:0000 from > the malloc routine. Consecutive malloc will not solve this problem. malloc returns NULL when there's no more memory left to allocate. Depending on what memory model you're using, you may not have had very much to start with. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@SDRC.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 "You know how Einstein got bad grades as a kid? Well MINE are even WORSE!" -Calvin
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/24/90)
In article <42900071@uicsrd.csrd.uiuc.edu> dkchen@uicsrd.csrd.uiuc.edu writes:
$ Recently I tried to port my program from an unix machine to my 386/20
$ running turbo/c. To my surprise, turbo/c sometimes returned ds:0000 from
$ the malloc routine. Consecutive malloc will not solve this problem.
$ I assume ds:0000 should be reserved as 'nil'. And printing data pointed
$ by pointer with value ds:0000 actually generate (null) as output. Am I
$ missing anything (such as compiler switches, etc.)? The turbo/c I used
$ is version 2.0. All comment are appreciated.
I believe that in the various memory models, a pointer consisting of all
zeroes is used as a NULL pointer. malloc () uses NULL to indicate that it
is unable to allocate the desired chunk of memory, so it sounds to me like
you're using too small a memory model. Turbo C defaults to the small
model (up to 64K of code and up to 64K of data); you may want to try out
the compact modem (up to 64K of code and the rest of memory available for
dynamically and statically allocated data).
BTW, due to the 8086 family's segmented architecture, any compiler
that lets you pick near or far addressing (and almost all C compilers do,
since there's a difference in performance and object code size) has several
different memory models available; your problem is not specific to either
your 386 or to Turbo C, so others may have the same problem with different
hardware and compilers.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."dkchen@uicsrd.csrd.uiuc.edu (03/25/90)
Thanks to those who responded and e-mailed. I solved the problem by using larger memory model. But I wish Turbo C can at least generate a warning showing that there is not enough memory around. Dean
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/27/90)
In article <42900072@uicsrd.csrd.uiuc.edu> dkchen@uicsrd.csrd.uiuc.edu writes: $ Thanks to those who responded and e-mailed. I solved the problem by $ using larger memory model. But I wish Turbo C can at least generate $ a warning showing that there is not enough memory around. This is a run-time problem, not a compile-time one. It's fine and dandy to have your compiler spitting out error messages and warnings, since they help you to improve your program. But I sure don't want the run-time package doing this! It's far better for your program to be able to handle such errors than to have these strange little messages appearing on a user's screen. It's a very easy task to detect whetehrg a malloc () call failed or not; simply replace foo = (bar *) malloc (sizeof (bar)); with if ((foo = (bar *) malloc (sizeof (bar))) == NULL) { /* error handling code */ } -- More half-baked ideas from the oven of: **************************************************************************** Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca <std_disclaimer.h> = "\nI'm only an undergraduate ... for now!\n";
dkchen@uicsrd.csrd.uiuc.edu (03/28/90)
All right. I know I already made myself a joke. It is the way the standard C works that returns NULL when there are not enough memory. Thanks to the people pointed this out for me and please ignore my previous response. Dean