home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / c / 2362 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  1.5 KB
  1. Path: sparky!uunet!utcsri!dgp.toronto.edu!flaps
  2. Newsgroups: comp.std.c
  3. From: flaps@dgp.toronto.edu (Alan J Rosenthal)
  4. Subject: Re: Aligning an arbitrary pointer?
  5. Message-ID: <1992Jul25.155641.22523@jarvis.csri.toronto.edu>
  6. References: <PDS.92Jul16111642@lemming.webo.dg.com> <1473f4INNq24@early-bird.think.com> <PDS.92Jul18154500@lemming.webo.dg.com> <14f6u9INNon7@early-bird.think.com> <PDS.92Jul21153918@lemming.webo.dg.com>
  7. Date: 25 Jul 92 19:56:42 GMT
  8. Lines: 18
  9.  
  10. pds@lemming.webo.dg.com (Paul D. Smith) writes:
  11. >I would
  12. >expect that on at least some systems the compiler will happily allow
  13. >you to assign 0x01381 (or some other non-aligned value) to an int*,
  14. >say, and then just core with a bus error (or otherwise die) when you
  15. ...
  16. >In fact I'd much rather it did that than quietly modify my pointer by
  17. >dropping bits... it would be a *major* pain to find *that* bug! :-)
  18.  
  19. One common reason for dropping the additional accuracy is when the pointers are
  20. actually of different format, so that the pointer-to-int cannot represent the
  21. finer-grained pointing.  For example, the machine may be word-addressed, so
  22. that (say) only every four eight-bit-bytes does the address go up by one (so
  23. like the pointers to adjacent ints will have adjacent internal values).
  24. Then a pointer-to-char may be larger than a pointer-to-int and contain the
  25. pointer-to-int's information plus a number which is 0, 1, 2, or 3.  A cast from
  26. pointer-to-char to pointer-to-int would simply have to throw away this second
  27. number.
  28.