> Dynamic allocation only saves memory when your program executes for a
> short period of time, or your program uses memory in such a way that
> memory fragmentation is a non issue
This depends in large part on the allocator you use, and minimization of
fragmentation is a basic goal of most memory allocator designs. I
certainly don't agree with the assertion that fragmentation issues are a
reason to discard dynamic memory allocation (although it may justify
discarding your current malloc() implementation).
A really good introduction to the issues involved in allocator design
is "Dynamic Storage Allocation: A Survey and Critical Review", by Wilson
et al at UTexas Austin. You can get it online at
ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps
As a specific counterexample to the argument you're making, compare memory
utilization between qmail (a program that relies almost entirely on
dynamic memory allocation, though not necessarilly all from malloc()) and
Sendmail (a program that relies comparitively heavily on fixed-size
buffers). qmail is a long-running program that uses dynamic memory in a
variety of different ways; shouldn't it cause far more swapping than
Sendmail? Why is qmail so much faster?
The security implications involved in this argument are obvious, and the
arguments against fixed-size buffers are compelling. Using fixed-size
buffers forces you to write significant amounts of code to track resource
usage, and when (note choice of words) this code fails, reliability is
impacted in a manner that frequently is exploitable by attackers. Using
dynamic memory allocation and abstracting the data types used simplifies
code and centralizes resource tracking.
In any case, I don't think any scientific arguments are being made here
about the performance implications of dynamic allocation, and the points
that have been made depend very heavily on the types of programs being
discussed. The original point that started this thread is that strncpy()
is dangerous, and my interpretation of the subsequent discussion is that
strncpy() is, as a security solution, inferior to dynamic memory
allocation. Amen!
Oh, and let's add one more item to the list of "strncpy considered
harmful" points:
The "count" provided to the counted string functions is of type size_t,
which is (on my machines) unsigned. This means that passing strncpy a
negative number results in a "count" parameter that effectively means
"infinity". I've seen at least one piece of code that had an exploitable
overrun because of a coding mistake involving pointer arithmatic that
resulted in strncpy() receiving a "count" of -1.
-----------------------------------------------------------------------------
Thomas H. Ptacek Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf "mmm... sacrilicious"