%p and MSC

Steve Summit scs at adam.mit.edu
Sun Aug 5 11:26:54 AEST 1990


In article <1990Aug2.232603.11944 at athena.mit.edu> I wrote:
>the Microsoft compilers are not ANSI-compliant in this regard.
>It's not an academic question, either; the correct and portable
>code
>	int *ip;
>	printf("%p\n", (void *)ip);
>will not function as intended under MSC if a small-data memory
>model is used...

I was at least partially wrong, as of MSC version 6.00.  Read on:

In article <444 at demott.COM> kdq at demott.COM (Kevin D. Quitt) writes:
>    %p represents a bug in Microsoft's documentation.
>testing... has indicated that MSC *is* ANSI compliant
>for those models where data and code have the same size pointer (S,L,H). 
>Those models with mixed addressing modes (C,M) cause a problem because
>it is impossible for printf to differentiate between code and data
>pointers.

Kevin is correct.  The cited behavior is new in MSC V6.0, though
not noted in the "what's new in V6.0" document (such as it is).
I wish they had mentioned it; I consider it a significant
improvement, and had been continuing to pollute my code with
now-unnecessary workarounds.

To make the point concrete, the code

	int i, *ip = &i;
	printf("%d %d %p %d %d\n", 1, 2, (void *)ip, 3, 4);

gives the following results under various model/version
combinations:

		MSC V5.10			MSC V6.00

	small	1 2 0003:0D6E 4 2180		1 2 0D7E 3 4

	large	1 2 16EF:0F42 3 4		1 2 1D50:0E42 3 4

The erroneous result is illustrated by the small-model code
compiled with V5.10: %p expects a 32-bit far pointer, but a
16-bit near pointer is passed, so a following argument (3) is
consumed for the segment part, and the last %d receives garbage.
Under V6.00 in small model, %p correctly pops and prints only a
16-bit pointer (evidently only the offset part, which is
reasonable).  Under either compiler version, the large-model %p
behavior is as expected.

I hereby retract some of the bile I spewed against Microsoft in
my previous posting on this topic.  (I wonder how extensive the
compact and medium model problems to which Kevin refers are?  Is
there a note, buried somewhere in the fully-updated documentation
I don't have yet, to the effect that ANSI compliance is only
guaranteed if you avoid compact and medium models?  I can't test
them, because I can't afford the disk space to keep four memory-
model-specific copies of the run-time libraries around.)

This has gotten very PC-specific, so I've redirected followups to
comp.sys.ibm.pc.programmer .

                                            Steve Summit
                                            scs at adam.mit.edu



More information about the Comp.lang.c mailing list