Whats the use of %p

[Keith Thompson]

Keith Thompson wrote: [...]

Quoting the standard:

The argument shall be a pointer to void. The value of the
pointer is converted to a sequence of printing characters,
in an implementation-defined manner.

Is it even guaranteed to vary across different pointers? I imagine
an output of, say, "here lieth a soggy pointer" would meet the
standard. It might not be considered an especially high quality
implementation.

I believe it's guaranteed that you can feed it to scanf %p and get a
pointer that is the same as [compares equal to] the original.

Yes. C99 7.19.6.2:

Matches an implementation-defined set of sequences, which should
be the same as the set of sequences that may be produced by the %p
conversion of the fprintf function. The corresponding argument
shall be a pointer to a pointer to void. The input item is
converted to a pointer value in an implementation-defined
manner. If the input item is a value converted earlier during the
same program execution, the pointer that results shall compare
equal to that value; otherwise the behavior of the %p conversion
is undefined.

Which implies that the result of printf("%p", ptr) is unique for each
unique pointer value, so CBFalconer's suggestion elsethread:

] Is it even guaranteed to vary across different pointers? I imagine
] an output of, say, "here lieth a soggy pointer" would meet the
] standard. It might not be considered an especially high quality
] implementation.

would not be conforming.

 

[Chris Torek]

... What (if any) is/are the use(s) of %p in printf in a situation where
the output isn't formatted as a number of some sort?

Others mentioned "segmentffset" style output (which one might
expect, and I believe did in fact get, on some 80x86 C compilers).
A more interesting example occurs on the IBM AS/400. I have not
used it but I have seen it described. In fact, google has
archived a message in which someone paraphrases the %p output
as:

SPP:0000 :1aefRMA_INTPTRMJK 070591 :10320:4:28

(search group comp.sys.ibm.as400.misc for "printf", "pointer", and
perhaps "%p").

 

[websnarf]

Thanks for the info Keith! Ok then my next questions at this point would be
these. What (if any) is/are the use(s) of %p in printf in a situation where
the output isn't formatted as a number of some sort?

On some systems, pointers are *NOT* numbers. In 16 bit DOS for
example, a pointer is a 16 bit segment and and 16 bit offset and may
look like: 0FDC:0110 for example.

[...] Are you still able to
determine the address by somehow deciphering the non-numerical sequence of
printing characters?

According to the quoted standard, that is not guaranteed.

[...] If not then is there any portable usefulness for %p in
printf?

No ... C is not a portable language, and this is merely one example of
why its not. This is just meant for system-level debugging. By
knowing what the %p format does on your system, you may be able to
understand what its output means, and that's all you really have.

 

[websnarf]

# >
# > What kind of formating can be done with %p in printf
# >
# There's never any point in printing out a pointer except to debug code.
# Hence no reason to format nicely for the user's consumption.

Creates unique strings for things like hash table keys.

How do you know that?

 

[Ian Malone]

Yes. C99 7.19.6.2:

Matches an implementation-defined set of sequences, which should
be the same as the set of sequences that may be produced by the %p
conversion of the fprintf function. The corresponding argument
shall be a pointer to a pointer to void. The input item is
converted to a pointer value in an implementation-defined
manner. If the input item is a value converted earlier during the
same program execution, the pointer that results shall compare
equal to that value; otherwise the behavior of the %p conversion
is undefined.

Which implies that the result of printf("%p", ptr) is unique for each
unique pointer value, so CBFalconer's suggestion elsethread:

] Is it even guaranteed to vary across different pointers? I imagine
] an output of, say, "here lieth a soggy pointer" would meet the
] standard. It might not be considered an especially high quality
] implementation.

would not be conforming.

Although implementing C with a scout troop and using their house
addresses as the output of %p would. Has this been tried I wonder?

 

[Michael Mair]

How do you know that?

As
void *bar;

fprintf(fptr, "%p", (void *)foo);
rewind(fptr);
fscanf("%p", &bar);

(checks omitted) gives you bar with foo==bar (C99, 7.19.6.2),
you can infer uniqueness of the conversion result.


Cheers
Michael

 

[Keith Thompson]

MrG{DRGN} wrote: [...]

[...] If not then is there any portable usefulness for %p in
printf?

No ... C is not a portable language, and this is merely one example of
why its not. This is just meant for system-level debugging. By
knowing what the %p format does on your system, you may be able to
understand what its output means, and that's all you really have.

Your statement, "C is not a portable language", is either meaningless
or false.

The question of whether C, as a language, is "portable" could mean any
of a number of things. If you measure portability by the number of
platforms on which it's been implemented, I suspect that C is more
portable than any other programming language. If you're talking about
portability of C programs, it's entirely possible to write C programs
that are portable to any conforming implementation.

Writing portable code in C is perhaps more work than writing portable
code in some other languages. Writing non-portable code in C is easy
to do deliberately, and perhaps too easy to do unintentionally.
Inferring from this that "C is not a portable language" is nonsense.

Or perhaps I've misunderstood your statement; can you clarify it?

 

[P.J. Plauger]

MrG{DRGN} wrote: [...]

[...] If not then is there any portable usefulness for %p in
printf?

No ... C is not a portable language, and this is merely one example of
why its not. This is just meant for system-level debugging. By
knowing what the %p format does on your system, you may be able to
understand what its output means, and that's all you really have.

Your statement, "C is not a portable language", is either meaningless
or false.

The question of whether C, as a language, is "portable" could mean any
of a number of things. If you measure portability by the number of
platforms on which it's been implemented, I suspect that C is more
portable than any other programming language. If you're talking about
portability of C programs, it's entirely possible to write C programs
that are portable to any conforming implementation.

Writing portable code in C is perhaps more work than writing portable
code in some other languages. Writing non-portable code in C is easy
to do deliberately, and perhaps too easy to do unintentionally.
Inferring from this that "C is not a portable language" is nonsense.

Or perhaps I've misunderstood your statement; can you clarify it?

He's trolling -- I did a couple laps around the barn with him a
month or two ago on the same subject.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[websnarf]

MrG{DRGN} wrote: [...]

[...] If not then is there any portable usefulness for %p in
printf?

No ... C is not a portable language, and this is merely one example of
why its not. This is just meant for system-level debugging. By
knowing what the %p format does on your system, you may be able to
understand what its output means, and that's all you really have.

Your statement, "C is not a portable language", is either meaningless
or false.

MrG{DRGN}, who claims to be a person new to C, asked the following
question:

[...] is there any portable usefulness for %p in printf?

Why do you think he's asking that? He has either some expectation, or
has read some propaganda somewhere suggesting that C is a portable
language. He sees this and realizes that its a blatant contradiction
of this notion. Being a new programmer to C, he has no stake in this.
He hasn't cherry picked some case to make C look bad. Its a
contradiction and that motivates him to ask the question.

And as you well know, there is an endless supply of these
"contradictions" for the C language. Your position, is to modify the
notion of portability, rather than simply accepting the mountain of
examples (each one by itself being sufficient) that basically tell you
that "C" is not, by itself, portable.

The question of whether C, as a language, is "portable" could mean any
of a number of things. If you measure portability by the number of
platforms on which it's been implemented,

Mutating the definition ... the word you are looking for is
"availability".

[...] I suspect that C is more portable than any other programming language.

No, by that measure assembly is more portable.

[...] If you're talking about
portability of C programs, it's entirely possible to write C programs
that are portable to any conforming implementation.

Its possible to write Fortran, BASIC, and Pascal programs that are also
portable as well. Its also possible to write programs which are
portable to multiple programming languages too (look up polygots).

Writing portable code in C is perhaps more work than writing portable
code in some other languages. Writing non-portable code in C is easy
to do deliberately, and perhaps too easy to do unintentionally.
Inferring from this that "C is not a portable language" is nonsense.

Ok, so you are saying, by that reasoning, that Fortran, BASIC and
Pascal are similarly portable languages then?

Or perhaps I've misunderstood your statement; can you clarify it?

Well, I think you just misunderstand the content of MrG{DRGN}'s
question. He's asking how can C be considered portable if %p formating
doesn't have portable semantics.

Why do you think stdint.h was added to the C99 standard? If C were a
portable language, why would anyone need such a file? The file should
basically be called "PortableIntegers.h" because that's what it is --
because the old C never hada portable integers. How is a language
supposed to be considered portable without portable integers?

For those that cannot let go of the notion that C is portable, you
simply mutate the meaning of portable and say that its ok for %p to be
different, and that doesn't affect portability. Its much like the
dogmatic religious who sit on the notions they believe and simply
mutate the world, science, logic, around them so that they can retain
their belief in the rightness of their religion.

 

[Keith Thompson]

MrG{DRGN} wrote: [...]
[...] If not then is there any portable usefulness for %p in
printf?

No ... C is not a portable language, and this is merely one example of
why its not. This is just meant for system-level debugging. By
knowing what the %p format does on your system, you may be able to
understand what its output means, and that's all you really have.

Your statement, "C is not a portable language", is either meaningless
or false.

MrG{DRGN}, who claims to be a person new to C, asked the following
question:

[...] is there any portable usefulness for %p in printf?

He asked a very simple question about a single feature, and you
insisted on making an inflammatory statement about the language as a
whole.

Why do you think he's asking that? He has either some expectation, or
has read some propaganda somewhere suggesting that C is a portable
language. He sees this and realizes that its a blatant contradiction
of this notion. Being a new programmer to C, he has no stake in this.
He hasn't cherry picked some case to make C look bad. Its a
contradiction and that motivates him to ask the question.

Or maybe he just wants to know whether there's any portable usefulness
for %p in printf.

[more nonsense snipped]

 

[MrG{DRGN}]

(e-mail address removed) writes:
-snip


Or maybe he just wants to know whether there's any portable usefulness
for %p in printf.

As Freud would say "Sometimes a cigar is just a cigar". I just wanted to
know whether there's any portable usefulness
for %p in printf.. I understand now that its implementation defined. That
being determined I now know when it might be prudent to use it, and when it
might not be. I'll refrain from any comments about a certain poser. This
might not be the best example, and it may not be written in all /standard/ C
but OpenGL is written in C and is supported on all UNIX® workstations, and
shipped standard with every Windows 95/98/2000/NT and MacOS PC, no other
graphics API operates on a wider range of hardware platforms and software
environments. OpenGL runs on every major operating system including Mac OS,
OS/2, UNIX, Windows 95/98, Windows 2000, Windows NT, Linux, OPENStep, and
BeOS; it also works with every major windowing system, including Win32,
MacOS, Presentation Manager, and X-Window System. OpenGL is callable from
Ada, C, C++, Fortran, Python, Perl and Java and offers complete independence
from network protocols and topologies. If that doesn't say something about
the portability of C then what does? Anyway lets get back to talking
positively about C please. I'm here to learn, not to piss into everyone's
oatmeal about this newsgroups topic of choice.

 

[David Holland]

>
> As
> void *bar;
>
> fprintf(fptr, "%p", (void *)foo);
> rewind(fptr);
> fscanf("%p", &bar);
>
> (checks omitted) gives you bar with foo==bar (C99, 7.19.6.2),
> you can infer uniqueness of the conversion result.

No, you can't. You're assuming it's deterministic, and that doesn't
follow from "implementation-defined".

Padding bits might introduce nondeterminism. So might, for example,
asking the operating system to report what internal object the pointer
points to and who (if anyone) it's shared with.

 

[Peter Nilsson]

... I'll refrain from any comments about a certain poser. ...

Beautiful!

 

[Michael Mair]

No, you can't. You're assuming it's deterministic, and that doesn't
follow from "implementation-defined".

Padding bits might introduce nondeterminism. So might, for example,
asking the operating system to report what internal object the pointer
points to and who (if anyone) it's shared with.

We are talking about strings not the pointer's internal representation.
I admit that the DS 9000 probably does not generate one unique but
a different string for every printf() invokation; the scanf(), however,
if conversion is successful _will_ give me the same pointer for all
output strings during the execution of the program. Otherwise, we
are not talking about a standard C implementation. Whatever problems
the operating system has and whatever sharing may mean does not play
the least role for the scanf() part of the conversion from the C point
of view.

Now, if we have padding bits which do not play a role for the pointer
value, it's of course a QOI question whether these are used for the
printf() conversion. I suspect that you will find about as many
implementations not doing this "right" as do make problems when
being confronted with the struct hack.

Cheers
Michael

 

[David Holland]

>
> We are talking about strings not the pointer's internal representation.

Yes, but the strings might be generated blindly from the internal
representation.

> I admit that the DS 9000 probably does not generate one unique but
> a different string for every printf() invokation; the scanf(), however,
> if conversion is successful _will_ give me the same pointer for all
> output strings during the execution of the program.

That's true, but the question was whether the strings were uniquely
determined. They'd better be if, as in the original contention,
someone's using them as hash keys. But this isn't guaranteed.