home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2357 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.9 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!uakari.primate.wisc.edu!caen!uwm.edu!rpi!scott.skidmore.edu!psinntp!psinntp!dg-rtp!webo!dg-webo!pds
  2. From: pds@lemming.webo.dg.com (Paul D. Smith)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Aligning an arbitrary pointer?
  5. Message-ID: <PDS.92Jul21153918@lemming.webo.dg.com>
  6. Date: 21 Jul 92 19:39:18 GMT
  7. References: <PDS.92Jul16111642@lemming.webo.dg.com>
  8.     <1473f4INNq24@early-bird.think.com> <PDS.92Jul18154500@lemming.webo.dg.com>
  9.     <14f6u9INNon7@early-bird.think.com>
  10. Sender: usenet@webo.dg.com (Usenet Administration)
  11. Organization: NSDD/ONSD, Data General Corp., Westboro, MA
  12. Lines: 49
  13. In-Reply-To: barmar@think.com's message of 20 Jul 1992 20:16:09 GMT
  14.  
  15. [] Regarding Re: Aligning an arbitrary pointer?;
  16. [] barmar@think.com (Barry Margolin) writes:
  17.  
  18.     bm> In article <PDS.92Jul18154500@lemming.webo.dg.com>
  19.     bm> pds@lemming.webo.dg.com (Paul D. Smith) writes:
  20.  
  21.     >I'm modifying an existing piece of code which allocates a huge
  22.     >chunk of memory then segments it into various parts, one of which
  23.     >is an array of structs (it's a page table).
  24.  
  25.     bm> On some systems, casting a pointer to a more restrictive type
  26.     bm> may have the effect of realigning it. [...]
  27.  
  28. Bleah :).  Maybe true, but certainly not Standard practice.  I would
  29. expect that on at least some systems the compiler will happily allow
  30. you to assign 0x01381 (or some other non-aligned value) to an int*,
  31. say, and then just core with a bus error (or otherwise die) when you
  32. tried to dereference the pointer (that's pretty much what happens on
  33. my RISC system :-)
  34.  
  35. In fact I'd much rather it did that than quietly modify my pointer by
  36. dropping bits... it would be a *major* pain to find *that* bug! :-)
  37.  
  38.     >For various reasons I don't want to introduce massive changes;
  39.     >the obvious way to do this properly is allocate the memory
  40.     >individually so I know it's properly aligned, but I don't want to
  41.     >change things that much.  I can't think of *any* other way to do
  42.     >it, actually.
  43.  
  44.     bm> Why not just declare a structure that contains the array and
  45.     bm> the preceding stuff?  The compiler will guarantee that the
  46.     bm> array is suitably aligned.
  47.  
  48. The preceding stuff is of dynamic size; it's read in from a file where
  49. the file contains the total size and interesting offsets.  The page
  50. table size has to be dynamic as well.
  51.  
  52. Anyway, I guess the consensus is that you can't do this in standard C,
  53. so that's all I wanted to know!  Thanks all...
  54. --
  55.  
  56.                                                                 paul
  57. -----
  58.  ------------------------------------------------------------------
  59. | Paul D. Smith                          |    paul_smith@dg.com    |
  60. | Data General Corp.                     | pds@lemming.webo.dg.com |
  61. | Network Systems Development Division   |                         |
  62. | Open Network Systems Development       |   "Pretty Damn S..."    |
  63.  ------------------------------------------------------------------
  64.