Whats the use of %p

[Spidey]

What kind of formating can be done with %p in printf

[MrG{DRGN}]

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...

we******@gmail. com writes:

-snip

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.

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.

--
MrG{DRGN}

[David Holland]

On 2006-02-27, Michael Mair <Mi**********@i nvalid.invalid> wrote:

Creates unique strings for things like hash table keys.

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.

No, you can't. You're assuming it's deterministic, and that doesn't
follow from "implementa tion-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.

--
- David A. Holland
(the above address works if unscrambled but isn't checked often)

[Peter Nilsson]

MrG{DRGN} wrote:

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

Beautiful!

--
Peter

[Michael Mair]

David Holland schrieb:

On 2006-02-27, Michael Mair <Mi**********@i nvalid.invalid> wrote:

> >>Creates unique strings for things like hash table keys.
> >
> > 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.

No, you can't. You're assuming it's deterministic, and that doesn't
follow from "implementa tion-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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[David Holland]

On 2006-03-03, Michael Mair <Mi**********@i nvalid.invalid> wrote:

David Holland schrieb:

On 2006-02-27, Michael Mair <Mi**********@i nvalid.invalid> wrote:

> >>Creates unique strings for things like hash table keys.
> >
> > 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.
No, you can't. You're assuming it's deterministic, and that doesn't
follow from "implementa tion-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.

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.

--
- David A. Holland
(the above address works if unscrambled but isn't checked often)