sinsterat_private Thu, 5 Mar 1998 14:21:36 -0800 > 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"
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:22 PDT