Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: %p and different pointer representations
Message-ID: <1890@dataio.Data-IO.COM>
Date: 27 Feb 89 18:22:40 GMT
References: <9382@bloom-beacon.MIT.EDU> <1089@vicorp.UUCP> <234@mstan.Morgan.COM> <16112@mimsy.UUCP> <9453@bloom-beacon.MIT.EDU>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 31

In article <9453@bloom-beacon.MIT.EDU> scs@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 *".
>Although this, I suppose, violates the standard, it's probably
>the right solution for that architecture, since not forcing a far
>pointer admits the possibility of losing information.
>I do think Microsoft's compromise was a good one,
>under the circumstances.  (A better one might have been to make
>%p strictly standard-conforming albeit potentially useless, and
>use %P as a nonstandard extension to force 32 bit pointers.)

Under Zortech's printf(), %p expects a pointer of the default data pointer
size. %lp always expects a far pointer.
Thus, to print each type of pointer in each memory model:
	void *		func *		void near *	void far *
S	%p		%p		%x		%lp
M	%p		%lp		%x		%lp
C	%p		%x		%x		%lp
L	%p		%p		%x		%lp

Things to note:
1. Using default data pointers, %p always works.
2. Using far pointers, %lp always works, it's easy to remember because
   of the similarity with %lx.
3. Using near pointers, %x always works. It seemed redundant to add a
   special flag for %p for near pointers, since %x did the job nicely.
4. Be careful using function pointers! A compromise is to cast them to
   (void far *), and use %lp on them.

P.S. I wrote it.