home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / os2 / programm / 4336 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.2 KB
  1. Xref: sparky comp.os.os2.programmer:4336 comp.lang.c:12548
  2. Path: sparky!uunet!ogicse!henson!news.u.washington.edu!milton!chuckb
  3. From: chuckb@milton.u.washington.edu (Chuck Bass)
  4. Newsgroups: comp.os.os2.programmer,comp.lang.c
  5. Subject: Re: malloc causes a segmentation violation!?
  6. Message-ID: <chuckb.714275722@milton>
  7. Date: 20 Aug 92 01:55:22 GMT
  8. Article-I.D.: milton.chuckb.714275722
  9. References: <1992Aug18.143135.6259@cc.tut.fi> <3dfy6bq@rpi.edu> <1992Aug19.155648.6210@funet.fi> <1992Aug19.171317.9312@bnr.ca>
  10. Sender: news@u.washington.edu (USENET News System)
  11. Organization: University of Washington
  12. Lines: 40
  13.  
  14.  
  15. >        For what it's worth, I got burned by getting internal errors in
  16. >malloc() and free(), then finding out that the reason for those errors was that
  17. >I was walking over memory that wasn't mine.  That experience made me a firm
  18. >believer in user-defined heap management, even if it is something as simple as
  19. >jacket routines (or macros) which control malloc and free.
  20.  
  21. >        The fact that the C spec permits implementations to provide a malloc
  22. >that returns only NULL is another compelling reason for the programmer not to
  23. >rely on directly calling malloc or free.
  24.  
  25. >        For portability and robustness, DON'T DIRECTLY USE malloc!
  26.  
  27.  
  28. >-- 
  29. >NOTE: I CAN'T SEND/RECEIVE E-MAIL HERE!!!  Use --> davisonj@ecn.purdue.edu <--
  30. >      During (roughly) August 20-25, I will be in transit.  Please be patient.
  31. >      The opinions and other information contained herein are not necessarily
  32. >      representative of Northern Telecom or any of its subsidiaries. 
  33.  
  34.  
  35.  I am wondering if this is common among people who program in C.
  36.  I haven't been programing in multiple environments (TurboC and
  37.  an SGI workstation only).  I write code that runs on both and
  38.  do *lots* of dynamic memory allocation.  Is this a bad habit,
  39.  terrible habit, good habit?  It seems to me that a general
  40.  program should be able to adjust to the required size
  41.  dynamically.  
  42.  
  43.  Anyhow your thoughts would be appreciated because I spent a lot
  44.  of time figuring out how to make dynamic memory allocation work
  45.  right... is this no longer in style?
  46.  
  47.  Later
  48.  
  49.  
  50. Chuck Bass
  51. College of Forest-Systems Engineering
  52. University of Washington
  53. chuckb@u.washington.edu
  54.