home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / cplus / 944 < prev    next >
Encoding:
Text File  |  1992-07-24  |  1.7 KB  |  47 lines

  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: bitwise logical operations on pointers
  5. Message-ID: <1992Jul24.175209.17306@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <2113@devnull.mpd.tandem.com>
  8. Date: Fri, 24 Jul 1992 17:52:09 GMT
  9. Lines: 36
  10.  
  11. rgp@seiko.mpd.tandem.com (Ramon Pantin) writes:
  12.  
  13. >Somewhere along the evolution of C this type of expressions where made illegal:
  14. >    char    *p = ...;
  15. >    p &= ~1;
  16.  
  17. >the workaround:
  18. >    p = (char *) ((int)p & ~1);
  19.  
  20. >makes my code:
  21. >    - harder to write
  22. >    - less portable because it assumes that there is an integral type
  23. >      (if not "int", "long") that has enough precision (bits) so that
  24. >      the casts will be harmless.
  25.  
  26. You could use 'unsigned long' rather than 'int' to improve the chances of
  27. the code working.
  28.  
  29. The workaround is not less portable, since bitwise operations on pointers
  30. are not portable at all.  Any such messing with pointers has to be
  31. confined to machine-specific modules to have any hope of porting your
  32. program.  If it makes sense to bit-twiddle a pointer, nothing prevents
  33. a compiler from providing an extension to do so -- the Standard only
  34. requires the compiler to have a way to diagnose such code as an error.
  35.  
  36. The reason the C Standard makes such twiddling illegal is that there is
  37. no way to specify semantics for it (in the context of a programming-
  38. language Standard).  It doesn't make any sense to me to say that a
  39. construct is completely legal but has no defined semantics.
  40.  
  41. Those things in the C Standard which have undefined behavior are
  42. those which are in general infeasible to detect at compile time.
  43. -- 
  44.  
  45. Steve Clamage, TauMetric Corp, steve@taumet.com
  46. Vice Chair, ANSI C++ Committee, X3J16
  47.