%p and different pointer representations

[Doug Gwyn]

In article <9453 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>Under Microsoft's PC C compiler (I don't know about others), %p
>expects a 32-bit ("far") pointer, in all memory models.  Therefore,
>the pointer passed must, in general, be cast to "void far *".

This is the essential botch in the MicroSoft implementation(s).
void * is REQUIRED to be big enough to hold ANY pointer to object
or incomplete type without loss of information, and %p is REQUIRED
to correspond to a void * (or char *, same representation).
If a void * is not big enough, you already have problems quite
apart from %p.

> 2. an 80x86 that supports mixed-model programming cannot support C.

A standard-conforming implementation of C must make a SINGLE definite
choice of how big each object type is.  This includes pointers.

>segmented architectures are a crime against the industry.

There is nothing inherently wrong with segmented architectures;
some of the nicest computers ever built have been segment-oriented.

Some programming languages (such as Fortran) do not fit well the
segment model, so implementations of such languages on segmented
machines aren't generally satisfactory, although they can be made
to work.  Other languages (such as Algol) are an almost perfect
match to the segemented model.  C is not a perfect fit (its main
problem on a segmented machine is implementing malloc() reasonably)
but it's pretty close.  Unfortunately, many programmers weaned on
the VAX (or similar architectures) have developed bad habits that
don't port to other architectures.

The real crime, in my opinion, was the introduction of several
"memory models" for C programming on the 80*86 architecture and the
subsequent attempt to link together things compiled under different
models.  I'm familiar with the rationale behind that, but I don't
agree with it.