🚀 go-pugleaf

In article <1992Jul24.175209.17306@taumet.com> steve@taumet.com (Steve Clamage) writes:
>rgp@seiko.mpd.tandem.com (Ramon Pantin) writes:
>
>>Somewhere along the evolution of C this type of expressions where made illegal:
>>	char	*p = ...;
>>	p &= ~1;
>
>>the workaround:
>>	p = (char *) ((int)p & ~1);
>
>>makes my code:
>>	- harder to write
>>	- less portable because it assumes that there is an integral type
>>	  (if not "int", "long") that has enough precision (bits) so that
>>	  the casts will be harmless.
>
>You could use 'unsigned long' rather than 'int' to improve the chances of
>the code working.

I already said 'if not "int", "long"' in my previous paragraph.

>
>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.  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.
Of course, a workaround based on unions of a pointer and an array of
some integral type could also be used (even more uglier code).

> ... Any such messing with pointers has to be
>confined to machine-specific modules to have any hope of porting your
>program.

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.

> ...  If it makes sense to bit-twiddle a pointer, nothing prevents
>a compiler from providing an extension to do so -- the Standard only
>requires the compiler to have a way to diagnose such code as an error.

Most ANSI-C compilers that I have tried this on simply say something
like "error: operators of different types".  Most compiler writters
seem to simply try to implement what the standard dictates and nothing
else.

>
>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."

>... It doesn't make any sense to me to say that a
>construct is completely legal but has no defined semantics.

How strong was the oposition within ANSI-C with respect to keeping
these traditional K&R semantics?  Were these semantics discarded
because of some purist sense of language design or was there some
vendor with bizare pointers strongly opposed to the acceptance
of these semantics?

>Those things in the C Standard which have undefined behavior are
>those which are in general infeasible to detect at compile time.
>-- 
>
>Steve Clamage, TauMetric Corp, steve@taumet.com
>Vice Chair, ANSI C++ Committee, X3J16

Thanks for your feedback.

Ramon Pantin