home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / cplus / 955 < prev    next >
Encoding:
Text File  |  1992-07-25  |  4.0 KB  |  87 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: <1992Jul25.163909.19241@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <2113@devnull.mpd.tandem.com> <1992Jul24.175209.17306@taumet.com> <2120@devnull.mpd.tandem.com>
  8. Date: Sat, 25 Jul 1992 16:39:09 GMT
  9. Lines: 76
  10.  
  11. rgp@mpd.tandem.com (Ramon Pantin) writes:
  12.  
  13. >>The workaround is not less portable, since bitwise operations on pointers
  14. >>are not portable at all.
  15.  
  16. >What an argument!  With K&R compilers and off the shelf 32 bit
  17. >processors: MIPS, Sparc, 88K, i[34]86 in 32 bit mode, VAX, NS-32X32,
  18. >VAX, RS/6000, etc (_long_ etc here) it is perfectly possible to write a
  19. >portable Virtual Memory Subsystem where the portable code (i.e. MMU
  20. >independent code) uses bitwise logical operations on pointers to
  21. >perform the splitting of an address into a page frame number and the
  22. >offset within the page.
  23.  
  24. Unfortunately, or perhaps fortunately, these are not the only machines
  25. in use with C and C++ compilers.  As discussed in the FAQ list for
  26. comp.lang.c, there are other machines, old and new, to which your code
  27. is not portable.  Some of these machines are designed for safe access to
  28. memory via pointers, and I would hope to see more, not fewer, of these
  29. designs in the future.
  30.  
  31. >Now, the same code could be used on a processor
  32. >were pointers are 64 bits and both "ints" and "longs" are 32 bits,
  33. >for example, with a compiler where some non-portable code would be
  34. >broken if "longs" were 64 bits.  Now if I use the "workaround", then
  35. >my pointers would get truncated to 32 bits, it is really _less_ portable.
  36.  
  37. Well, let me turn your own argument back on you:  I don't care about
  38. machines with 64-bit pointers, so I don't care if casting a pointer
  39. to a long doesn't work on them.  (You forgot to mention machines with
  40. 48-bit pointers, but I don't care about them either.)  Do you find this
  41. attitude inappropriate?  So do I.  I also don't think it makes sense
  42. to say whether one unportable construct is "less portable" than another
  43. (in the context of a language Standard).
  44.  
  45. >For the class of machines that I'm interested in, my K&R code is portable
  46. >among them, no need to call it machine-specific in this case.
  47.  
  48. Again, there are other machines that other programmers care about.  A
  49. question which must be addressed is which machines shall be disparaged
  50. by the language Standard.  What will be the impact of making it
  51. impossible to make a conforming compiler on those machines?
  52.  
  53. >>The reason the C Standard makes such twiddling illegal is that there is
  54. >>no way to specify semantics for it (in the context of a programming-
  55. >>language Standard).
  56.  
  57. >The semantic would be "the logical bitwise operation is performed
  58. >on the raw bits of the pointer storage with the semantics of the
  59. >operation being exactly the same as the semantics for the operation
  60. >on an unsigned integral type on that machine."
  61.  
  62. No, that is not a language semantic specification, that is an
  63. implementation specification.  If I have a pointer to an object
  64. of a specified type, the Standard defines what it means to perform
  65. various operations on it.  I can dereference it and get the object.
  66. I can add 1 to it and get the address of the next object in the
  67. array of objects (if there is one).
  68.  
  69. Suppose we allow:
  70.     T* p = ...;
  71.     int i = ...;
  72.     ... p & i ...
  73. What is the type of this expression?  It isn't T*, since in general it
  74. will not point to an object of type T.  Is it void*?  If so, what can
  75. I do with this void*?  Can I cast it to some type on which operations may
  76. be performed?  Remember that guarantees about casting from void* apply
  77. only when casting a pointer value back to its original type.
  78.  
  79. I don't think you can find sensible (in a language Standard context)
  80. answers to these questions.  Your answers have to make sense on all
  81. machines for which it is otherwise possible to have a conforming C or
  82. C++ compiler.  Otherwise all you could say is "undefined".
  83. -- 
  84.  
  85. Steve Clamage, TauMetric Corp, steve@taumet.com
  86. Vice Chair, ANSI C++ Committee, X3J16
  87.