Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!daemon
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Novice MicroSoft C5.1 question
Message-ID: <1990Aug2.232603.11944@athena.mit.edu>
Date: 2 Aug 90 23:26:03 GMT
References: <17179@haddock.ima.isc.com> <440@demott.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: scs@adam.mit.edu (Steve Summit)
Organization: Thermal Technologies, Inc.
Lines: 52

In article <17179@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>
>For portable usage, you should cast the pointer to (void *); it's not always
>true that `int *' and `void *' have the same representation.  Apparently MSC
>requires you to also use the `far' keyword in some memory models, but if they
>claim to be standard conforming, that's a bug%.

In article <440@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes:
>   MSC's %p prints the pointer in the format SSSS:OOOO (segment/offset), with
>%Np printing only the OOOO portion.  Both forms expect a 32 bit pointer,
>so non-32 bit pointers must be coerced by using the far keyword.

The Standard does not say anything about near and far pointers.
The Standard says that if you pass a void * to %p, the pointer
will be printed in some machine-dependent way.  Karl is correct;
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, while the "Microsoft compliant" code

	printf("%p\n", (void far *)ip);

is obviously not portable to compilers without a nonstandard far
keyword.  %p can be quite useful, if only when debugging; it's a
miserable pain to have to surround usages of it with #ifdef MSC
or the like when Microsoft compilers are in use.

It has been observed that other segmented architecture/language
combinations than 80*86/C do not make the existence of segments
so manifestly visible at the HLL source level.  Why should a C
programmer be intimately concerned with segments and offsets and
near and far pointers?  (The answer, of course, is obvious:
transparency would most easily be implemented by having "large
model" the default, which would clearly be far "too inefficient.")
Microsoft C v6.0 makes the problem worse, not better: programmers
are encouraged to make use of the new "based pointers" to
"control placement of data in segments and generate better code
for far-pointer manipulation" (this according to the marketing
hype in the compiler documentation).  It looks to me like based
pointers are merely less portable and more confusing.  (I
shouldn't have gone off on this tangent; now the Intel and
Microsoft apologetics will rush to the defense and I'll have
started a flame war...)

                                            Steve Summit
                                            scs@adam.mit.edu