🚀 go-pugleaf

>        For what it's worth, I got burned by getting internal errors in
>malloc() and free(), then finding out that the reason for those errors was that
>I was walking over memory that wasn't mine.  That experience made me a firm
>believer in user-defined heap management, even if it is something as simple as
>jacket routines (or macros) which control malloc and free.

>        The fact that the C spec permits implementations to provide a malloc
>that returns only NULL is another compelling reason for the programmer not to
>rely on directly calling malloc or free.

>        For portability and robustness, DON'T DIRECTLY USE malloc!


>-- 
>NOTE: I CAN'T SEND/RECEIVE E-MAIL HERE!!!  Use --> davisonj@ecn.purdue.edu <--
>      During (roughly) August 20-25, I will be in transit.  Please be patient.
>      The opinions and other information contained herein are not necessarily
>      representative of Northern Telecom or any of its subsidiaries. 

 
 I am wondering if this is common among people who program in C.
 I haven't been programing in multiple environments (TurboC and
 an SGI workstation only).  I write code that runs on both and
 do *lots* of dynamic memory allocation.  Is this a bad habit,
 terrible habit, good habit?  It seems to me that a general
 program should be able to adjust to the required size
 dynamically.  

 Anyhow your thoughts would be appreciated because I spent a lot
 of time figuring out how to make dynamic memory allocation work
 right... is this no longer in style?

 Later


Chuck Bass
College of Forest-Systems Engineering
University of Washington
chuckb@u.washington.edu