Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!ucbvax!ulysses!cjc
From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav])
Newsgroups: comp.lang.c
Subject: Re: %p and different pointer representations
Summary: portability of %p and segmented architectures
Message-ID: <11269@ulysses.homer.nj.att.com>
Date: 27 Feb 89 20:40:38 GMT
References: <16112@mimsy.UUCP> <173@cbnewsc.ATT.COM>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 46

>  In article <234@mstan.Morgan.COM> dff@Morgan.COM (Daniel F. Fisher) writes:
> >To what type should a pointer argument be cast when passing it to
> >fprintf() for printing using the %p conversion specifier?
> >First Example: In an IBM-PC implementation with small-data,
> >large-code, the data pointers (int *), (char *), etc. are all 16
> >bits., but function pointers (int (*)()), etc. are all 32 bits.
> >So if I wish to print a function pointer, I cannot cast it to a
> >data pointer without losing information.
> 
> In TURBO C, you can do:
> 	int *p;
> 	printf("%Fp",(void far *)p);
> in ANY MEMORY MODEL, for any size of data pointer p, and get printed
> "XXXX:YYYY", where XXXX is the segment, and YYYY is the offset for pointer p.
> If p is a small data pointer, DS will be supplied by the compiler.
> Note that using the "near" keyword is dangerous in a large-data memory model,
> because DS != SS, and DS is supplied when converting near pointers to far
> pointers. I believe that the keywords "_ds", "_es", and "_ss" are intended
> to permit proper use of small pointers in a large-pointer memory model.

[Other examples and arguments deleted]

#define Flame

Yes, but the whole point of %p and void is to make such things
_more_ portable, where as this example _only_ works on 80*86
architectures, and relies on keywords that aren't even part of C,
but are a non-conforming polution of keyword name space invented
for IBM PC compilers.

#undef Flame

The point is, %ld works on 99% of the machines out there now,
why should I use %p if it makes things even less portable?
The representation of the pointer is non-portable,
but accessing it should not be.  I can see that you
don't really need to pass around function pointers as void*,
but there should be a way of printing their values!
However, please don't give me
	%h - prints a pointer to a function
	     (h is the first free letter after f, which is taken)
-- 
Name:			Christopher J. Calabrese
Brain loaned to:	AT&T Bell Laboratories, Murray Hill, NJ
att!ulysses!cjc		cjc@ulysses.att.com
Obligatory Quote:	``Now, where DID I put that bagel?''