🚀 go-pugleaf

rgp@mpd.tandem.com (Ramon Pantin) writes:

>>The workaround is not less portable, since bitwise operations on pointers
>>are not portable at all.

>What an argument!  With K&R compilers and off the shelf 32 bit
>processors: MIPS, Sparc, 88K, i[34]86 in 32 bit mode, VAX, NS-32X32,
>VAX, RS/6000, etc (_long_ etc here) it is perfectly possible to write a
>portable Virtual Memory Subsystem where the portable code (i.e. MMU
>independent code) uses bitwise logical operations on pointers to
>perform the splitting of an address into a page frame number and the
>offset within the page.

Unfortunately, or perhaps fortunately, these are not the only machines
in use with C and C++ compilers.  As discussed in the FAQ list for
comp.lang.c, there are other machines, old and new, to which your code
is not portable.  Some of these machines are designed for safe access to
memory via pointers, and I would hope to see more, not fewer, of these
designs in the future.

>Now, the same code could be used on a processor
>were pointers are 64 bits and both "ints" and "longs" are 32 bits,
>for example, with a compiler where some non-portable code would be
>broken if "longs" were 64 bits.  Now if I use the "workaround", then
>my pointers would get truncated to 32 bits, it is really _less_ portable.

Well, let me turn your own argument back on you:  I don't care about
machines with 64-bit pointers, so I don't care if casting a pointer
to a long doesn't work on them.  (You forgot to mention machines with
48-bit pointers, but I don't care about them either.)  Do you find this
attitude inappropriate?  So do I.  I also don't think it makes sense
to say whether one unportable construct is "less portable" than another
(in the context of a language Standard).

>For the class of machines that I'm interested in, my K&R code is portable
>among them, no need to call it machine-specific in this case.

Again, there are other machines that other programmers care about.  A
question which must be addressed is which machines shall be disparaged
by the language Standard.  What will be the impact of making it
impossible to make a conforming compiler on those machines?

>>The reason the C Standard makes such twiddling illegal is that there is
>>no way to specify semantics for it (in the context of a programming-
>>language Standard).

>The semantic would be "the logical bitwise operation is performed
>on the raw bits of the pointer storage with the semantics of the
>operation being exactly the same as the semantics for the operation
>on an unsigned integral type on that machine."

No, that is not a language semantic specification, that is an
implementation specification.  If I have a pointer to an object
of a specified type, the Standard defines what it means to perform
various operations on it.  I can dereference it and get the object.
I can add 1 to it and get the address of the next object in the
array of objects (if there is one).

Suppose we allow:
	T* p = ...;
	int i = ...;
	... p & i ...
What is the type of this expression?  It isn't T*, since in general it
will not point to an object of type T.  Is it void*?  If so, what can
I do with this void*?  Can I cast it to some type on which operations may
be performed?  Remember that guarantees about casting from void* apply
only when casting a pointer value back to its original type.

I don't think you can find sensible (in a language Standard context)
answers to these questions.  Your answers have to make sense on all
machines for which it is otherwise possible to have a conforming C or
C++ compiler.  Otherwise all you could say is "undefined".
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16