home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3058 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  1.5 KB
  1. Path: sparky!uunet!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: malloc(0)
  5. Message-ID: <19171@ksr.com>
  6. Date: 23 Nov 92 11:24:55 EST
  7. References: <1ejhrnINN5it@ftp.UU.NET> <1992Nov21.005207.9741@lucid.com> <2305@sdrc.COM> <3918@dozo.and.nl>
  8. Sender: news@ksr.com
  9. Lines: 27
  10.  
  11. jos@and.nl (Jos Horsmeier) writes:
  12. >In article <2305@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
  13. >|That was indeed the committee's intent.  If every call for zero space
  14. >|returned the same pointer it wouldn't be very unique, would it?
  15. >No it wouldn't, but if it would return a unique pointer value,it would
  16. >brake code like this:
  17. >char *p= malloc(0);
  18. >char *q= malloc(0);
  19. >if (p == q)
  20. >    printf("malloc returned NULL or non-unique value"\n");
  21. >else
  22. >    printf("malloc returned two unique pointers\n");
  23.  
  24. I would certainly hope it would brake code like that.  Putting a stop to
  25. code like that is valuable.  :-)
  26.  
  27. >when ported from a system where malloc(0) returns NULL to a system
  28. >where malloc would return a unique pointer every time it was 
  29. >called with a size of zero ...
  30.  
  31. Anyone who tests for whether or not malloc(0) returned NULL by testing
  32. whether or not the new malloc(0) returned the same as a previous malloc(0)
  33. deserves to have their programming career braked, too.
  34.  
  35. [For the non-native English speakers in the audience, in between the valid
  36. technical points here I am having fun with Jos' misspelling of "break" (to
  37. damage or destroy) as "brake" (to slow or stop).]
  38.