Old Wolf said:
It means you run the risk of running out of memory, not to
mention memory fragmentation.
Suppose you have a system with 64K of memory, and your application
does some dynamic allocation. It all works fine, until other
applications are loaded onto the system, and then one day when they
all happen to have malloc'd at once , the system crashes and everybody
blames everyone else's application. This is doubly important if the
crashed happened at an important time (eg. during open heart surgery).
Open heart surgery with a machine that has 64K memory?
On the reality side, most modern operating systems
today use virtual memory and isolate each application
(i.e., "process") within its own virtual space. E.g.,
address 0x1000 translates to a different piece of real
memory for each application. The system crashes only
when it runs out of paging space on the harddrive. Then
it's a problem of simply running too many processes at
the same time. It's not the fault of the application,
but the users that loaded too many applications on
the same box at the same time.
It's far more reliable to allocate all memory at compile-time
(ie. a fixed-size stack, and no malloc calls). You can inspect
your code to ensure that the stack will never overflow.
That only moves the fragmentation from malloc()
to stackframe management. Stackframe memory and
malloc() memory come from the same place. The
stack frame is fixed-size, but the compiler cannot
determine how much memory is needed for all stack
frames (recursive calls, function pointer calls).
Most real world problems are solved much more
efficiently with malloc() memory than swagging
a giant array on the stackframe. Load up too
many of those kinds of programs and you have
the same problems as too many malloc()-style
programs running at the same time.
I have heard of systems that support malloc() (just to be conforming)
but always fail (return NULL). Others just don't bother
with the rigmarole and don't support it.
Design your C programs to use stack frame
memory and heap memory using prudent policies,
rather than fearing that someday your program
will be ported to a Deathstation2000. Stay
grounded in the real world.
--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!