home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / programm / 7089 < prev    next >
Encoding:
Text File  |  1992-11-08  |  1.5 KB  |  41 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!think.com!rpi!psinntp!psinntp!cgrafx!brian
  3. From: brian@chromagrafx.com (Brian C. Hobbs)
  4. Subject: NXZoneMalloc is your friend... NXBitmapImageRep is not.
  5. Message-ID: <1992Nov7.003348.343@chromagrafx.com>
  6. Sender: brian@chromagrafx.com
  7. Organization: Chromagrafx Imaging Systems, Hauppauge, NY
  8. Date: Sat, 7 Nov 1992 00:33:48 GMT
  9. Lines: 30
  10.  
  11.  
  12. Greetings,
  13.  
  14. Just a curious question:  Are developers experiencing more memory  
  15. corruption errors of bugs (i.e. invalid memory access, writing over  
  16. existing data, etc...) using 3.0 than 2.1?  It seems that I've got to  
  17. explicitly NXZoneMalloc off everything I do just so the memory is there  
  18. and protected.
  19.  
  20. Also... this is more of an "intuition" thing... I've talked to NeXT about  
  21. it but I don't know if it's valid and I can't give any examples here:   
  22. I've had some corruption problems using [[NXBitmapImageRep alloc]  
  23. initData:NULL ...] different times on multiple machines on multiple apps  
  24. that I'm writing.  However, if I malloc the memory myself and pass the  
  25. pointer to initData, the problem goes away. (nifty methods, +sizeImage:  
  26. and such.)
  27.  
  28. The moral of this story:
  29.  
  30. Don't be lazy.  NXZoneMalloc off everything you can.  Especially on large  
  31. sections of memory like images.  Stay away from:
  32.  
  33. unsigned char imageData[justHowMuchCanIPutInHereAnyways:)]
  34.  
  35. Brian Hobbs
  36. Chromagrafx Imaging Systems
  37. brian@chromagrafx.com
  38.  
  39. "NXZoneMalloc and NXBitmapImageRep.  Use them together.  Use them in  
  40. peace."
  41.