home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / aix / 13173 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  1.5 KB

  1. Path: sparky!uunet!gatech!concert!duke!trt
  2. From: trt@duke.cs.duke.edu (Tom Truscott)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: malloc(0) fails on AIX ... etc.
  5. Message-ID: <726705103@romeo.cs.duke.edu>
  6. Date: 10 Jan 93 22:31:44 GMT
  7. References: <31480@nntp_server.ems.cdc.com> <1993Jan9.161925.5124@idsssd.UUCP>
  8. Organization: IBM RTP
  9. Lines: 26
  10.  
  11. > But, think of the threads that would open complaining that "it doesn't error
  12. > when I malloc(0) ... shouldn't it return an error?" ...
  13.  
  14. I don't think this would happen.  malloc(0) for years has returned a unique
  15. pointer on SunOS, Ultrix, HP-UX, ... and I have yet to see anyone complain.
  16. On the other hand I have seen a never ending stream of complaints
  17. about systems where malloc(0) fails.
  18.  
  19. The only argument I have *ever* heard for malloc(0) failing is that
  20. it is "required by the SVID".  (Could someone please quote chapter
  21. and verse where it is required, and not merely permitted?)
  22. Does 100% SVID compliance make AIX dead right?
  23.  
  24. Of course portable programs must defend against malloc() nonsense.
  25. (The correct coding is non-obvious, as previous articles have revealed.)
  26. But this is a poor justification for continuing the AIX malloc behavior!
  27.  
  28. This thread reminds me of the ancient debate about left-shifting by 0.
  29. In some C implementations (i << n) was undefined when n == 0
  30. since the hardware did not efficiently support it.
  31. There were people who didn't want to see left shift slowed down just
  32. to handle a dubious and rare special case.
  33. After all, this could be handled portably with:
  34.     (n == 0)? i: (i << n)
  35.  
  36. Tom Truscott
  37.