home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / bsd / 10809 < prev    next >
Encoding:
Text File  |  1993-01-01  |  1.2 KB  |  29 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!pipex!demon!gtoal
  3. From: gtoal@pizzabox.demon.co.uk (Graham Toal)
  4. Subject: Re: [386bsd] GNU malloc in favor of BSD malloc in libc - shall we vote?
  5. Message-ID: <C05wCD.Bp0@demon.co.uk>
  6. Sender: news@demon.co.uk
  7. Nntp-Posting-Host: pizzabox.demon.co.uk
  8. Organization: Cuddlehogs Anonymous
  9. References: <1hvu79INNjqq@ftp.UU.NET> <1993Jan1.001332.15123@serval.net.wsu.edu> <1i0cnoINNiu2@life.ai.mit.edu>
  10. Date: Fri, 1 Jan 1993 06:21:48 GMT
  11. Lines: 16
  12.  
  13. In article <1i0cnoINNiu2@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
  14. :In article <1993Jan1.001332.15123@serval.net.wsu.edu> hlu@eecs.wsu.edu
  15. :(H.J. Lu) writes:
  16. :> Another `feature' in GNU malloc is malloc (0) returns NULL.
  17. :According to ANSI, malloc(0) is implementation-defined.  I believe some
  18. :systems intentionally return a bogus(?) address so that sloppy programs
  19. :don't have to think about it.
  20. :
  21. :Obviously, you can't write or read at the address returned by malloc(0)
  22. :anyway; what difference can it really make?
  23.  
  24. It makes a difference when you realloc.  NULL is fine by me though.
  25. Relying on a pointer to a piece of memory that you can't access seems
  26. to me to be even more sloppy.
  27.  
  28. G
  29.