home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3425 < prev    next >
Encoding:
Text File  |  1993-01-26  |  1.7 KB  |  48 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!uunet.ca!canrem!dosgate!dosgate![peter.curran@canrem.com]
  3. From: "peter curran" <peter.curran@canrem.com>
  4. Subject: Is this allowed in C?
  5. Message-ID: <1993Jan26.4502.4824@dosgate>
  6. Reply-To: "peter curran" <peter.curran@canrem.com>
  7. Organization: Canada Remote Systems
  8. Distribution: comp
  9. Date: 26 Jan 93 07:08:35 EST
  10. Lines: 36
  11.  
  12.  
  13. In <1993Jan22.012502.5241#nntpd.lkg.dec.com> diamond@jit533.jit.dec.com
  14.                        (Norman Diamond) writes..
  15.  
  16. [original problem deleted]
  17.  
  18. ND>The C standard guarantees that whenever malloc() succeeds ... the
  19. ND>value will point to storage suitably aligned for everything,....
  20.  
  21. This leads me to a question:
  22.  
  23.           void *p;
  24.    p = malloc(1);
  25.  
  26. Are there any alignment restrictions on the allocated memory?
  27. Assuming, for example, sizeof(double) > 1, a double cannot be
  28. stored here, so does the memory have to be suitably aligned for
  29. use as a "double *?"  Section 4.10.3 appears to me to be
  30. sufficiently ambiguous that this is unclear.
  31.  
  32. I have on occasion needed addresses to serve as "markers"
  33. (addresses that will not match any real object, nor NULL), and
  34. have accomplished this by allocating objects that will never
  35. really be used.  I could save some (probably trivial amount of)
  36. memory by allocating single bytes for the purpose, but was
  37. never sure that something strange couldn't happen if the
  38. address wsan't properly aligned, even if nothing tried to
  39. derefernce it.
  40.  
  41. Peter Curran                          FidoNet: 1:229/15
  42. Usenet: peter.curran@canrem.com       RIME:    CRS (#118)
  43. ---
  44.  ■ DeLuxe² 1.25 #12339 ■ 
  45. --
  46. Canada Remote Systems  - Toronto, Ontario
  47. World's Largest PCBOARD System - 416-629-7000/629-7044
  48.