home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2600 < prev    next >
Encoding:
Text File  |  1992-09-10  |  1.4 KB  |  37 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: calloc()
  5. Message-ID: <1992Sep10.180542.1009@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <14455@goanna.cs.rmit.oz.au>
  8. Date: Thu, 10 Sep 1992 18:05:42 GMT
  9. Lines: 26
  10.  
  11. ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
  12.  
  13. >Now I wonder:  if I want to allocate an array with elements of known size
  14. >but with number of elements not known until run-time, and if I don't really
  15. >care what the initial contents are, _is_ there something in the standard to
  16. >make
  17. >    p = calloc(NumberOfElements, sizeof *p)
  18. >better than
  19. >    p = malloc(NumberOfElements * sizeof *p) ?
  20.  
  21. No.  The only required difference is the calling sequence and that
  22. calloc clears the memory to all bits zero.
  23.  
  24. That said, suppose we have a system where int and size_t are 16 bits,
  25. but it is possible to allocate an object bigger than 64K.  A
  26. careful library implementor would ensure that a call like
  27.     calloc(68, 1000)
  28. did not result in integer overflow inside calloc, but would allocate
  29. 68000 bytes.  You couldn't do that with (ordinary) malloc.  (I
  30. actually had to implement this on a pre-Standard system one time.)
  31. I don't think the Standard requires this sort of care, but I would
  32. expect it from a quality implementation.
  33. -- 
  34.  
  35. Steve Clamage, TauMetric Corp, steve@taumet.com
  36. Vice Chair, ANSI C++ Committee, X3J16
  37.