Whats the use of %p

[Spidey]

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

 

[Roka]

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

To print out an address.
eg.

char *p = "abc";
printf("The address of *abc* is %p\n",p);
printf("The address of p is %p\n",&p);


result may be:
The address of *abc* is 0x804841c
The address of p is 0xbffff474

 

[Richard Bos]

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

None. You can use it to print a pointer value; how the output is
formatted is entirely up to the implementation.

Richard

 

[Keith Thompson]

To print out an address.
eg.

char *p = "abc";
printf("The address of *abc* is %p\n",p);
printf("The address of p is %p\n",&p);


result may be:
The address of *abc* is 0x804841c
The address of p is 0xbffff474

"%p" expects a void* argument. Giving it a char* is ok (but poor
style IMHO); giving it char** is likely to work, but is strictly
speaking non-portable.

char *p = "abc";
printf("The address of *abc* is %p\n", (void*)p);
printf("The address of p is %p\n", (void*)&p);

 

[pete]

Keith Thompson wrote:

"%p" expects a void* argument. Giving it a char* is ok (but poor
style IMHO);

I don't like the wording of the standard in repeated footnotes
on the issue of same representation
meaning to imply interchangability.

C99
6.2.5 Types
31)The same representation and alignment requirements are
meant to imply interchangeability as arguments to
functions, return values from functions, and members of
unions.
39)The same representation and alignment requirements are
meant to imply interchangeability as arguments to
functions, return values from functions, and members of
unions.

Why doesn't the normative part of the standard just say
that it does or doesn't imply interchangeability?

 

[Wojtek Lerch]

I don't like the wording of the standard in repeated footnotes
on the issue of same representation
meaning to imply interchangability.

C99
6.2.5 Types
31)The same representation and alignment requirements are
meant to imply interchangeability as arguments to
functions, return values from functions, and members of
unions.
39)The same representation and alignment requirements are
meant to imply interchangeability as arguments to
functions, return values from functions, and members of
unions.

Why doesn't the normative part of the standard just say
that it does or doesn't imply interchangeability?

Because it would then have to explain, in detail, what situations the
interchangeability applies to, and that's a lot of work. To quote myself
from another thread:

: I know of two places in the normative text that describe situations where
a
: signed type and the corresponding unsigned type are interchangeable as
: arguments to functions, and those two places are quite clear already:
: 6.5.2.2p6 (calls to a function defined without a prototype) and 7.15.1.1p2
: (va_arg()). If there are supposed to be more such situations, then I'm
: afraid the footnote itself needs to be clarified. In particular, if the
: only difference between two function types T1 and T2 is in the signedness
of
: parameters, was the intent that the two types are compatible, despite of
: what 6.7.5.3p15 says? If not, which ones of the following were intended
to
: apply, if any:
:
: - it's OK to use an expression with type T1 to call a function that was
: defined as T2, even though 6.5.2.2p6 says it's undefined behaviour?
:
: - it's OK to declare the function as T1 in one translation unit and define
: as T2 in another translation unit, even though 6.2.7p1 says it's undefined
: behaviour?
:
: - it's OK to define the function as T1 and then as T2 in *the same*
: translation unit, even though 6.7p4 says it's a constraint violation?
:
: What about interchangeability as return values from function? I haven't
: found any normative text that implies this kind of interchangeability;
which
: of the above three situations are meant to apply if T1 and T2 have
different
: return types?

 

[pete]

Because it would then have to explain, in detail, what situations the
interchangeability applies to, and that's a lot of work. To quote myself
from another thread:

: I know of two places in the normative text that describe situations where
a
: signed type and the corresponding unsigned type are interchangeable as
: arguments to functions, and those two places are quite clear already:
: 6.5.2.2p6 (calls to a function defined without a prototype) and 7.15.1.1p2
: (va_arg()). If there are supposed to be more such situations, then I'm
: afraid the footnote itself needs to be clarified. In particular, if the
: only difference between two function types T1 and T2 is in the signedness
of
: parameters, was the intent that the two types are compatible, despite of
: what 6.7.5.3p15 says? If not, which ones of the following were intended
to
: apply, if any:
:
: - it's OK to use an expression with type T1 to call a function that was
: defined as T2, even though 6.5.2.2p6 says it's undefined behaviour?
:
: - it's OK to declare the function as T1 in one translation unit and define
: as T2 in another translation unit, even though 6.2.7p1 says it's undefined
: behaviour?
:
: - it's OK to define the function as T1 and then as T2 in *the same*
: translation unit, even though 6.7p4 says it's a constraint violation?
:
: What about interchangeability as return values from function? I haven't
: found any normative text that implies this kind of interchangeability;
which
: of the above three situations are meant to apply if T1 and T2 have
different
: return types?

I like to use linked lists with generic data pointers.
Is the cast in new.c, completely redundant?

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
struct list_node {
struct list_node *next;
void *data;
} node;
char *string = "string";

node.data = string;
puts((char *)node.data);
return 0;
}

/* END new.c */

 

[Wojtek Lerch]

Is the cast in new.c, completely redundant? ....
#include <stdio.h> ....
struct list_node { ....
void *data;
} node; ....
puts((char *)node.data);

Yes, because <stdio.h> provides a prototype for puts() that causes an
implicit conversion. But if you used printf and %s instead, it would depend
on whether you want to rely on what "everybody knows" the intent was, or
only on what a strict reading of the words promises (and depending on who
reads them).

 

[pete]

Yes, because <stdio.h> provides a prototype for puts() that causes an
implicit conversion.
But if you used printf and %s instead,

part_fprint is the example that I should have given,
because I actually do use the fprintf function that way.

void part_fprint(FILE *stream, list_type *node)
{
while (node != NULL) {
fprintf(stream, "%s\n", (char *)node -> data);
node = node -> next;
}
}

it would depend
on whether you want to rely on what "everybody knows"
the intent was, or only on what a strict reading of the
words promises (and depending on who reads them).

Thank you.
I'll keep the cast in part_fprint.

 

[Wojtek Lerch]

: - it's OK to define the function as T1 and then as T2 in *the same*

^^^^^^
I meant "declare", of course.

 

[Douglas A. Gwyn]

Why doesn't the normative part of the standard just say
that it does or doesn't imply interchangeability?

Because that would require a whole lot of additional
definition of terms (some of them hard to define
exactly the way we want them), which we can leave up
to "common understanding" when we use them in footnotes.

 

[Malcolm]

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.

 

[SM Ryan]

# >
# > 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.

 

[MrG{DRGN}]

None. You can use it to print a pointer value; how the output is
formatted is entirely up to the implementation.

Richard by the above do you mean that the output of %p is not guaranteed to
be in hexadecimal format?(as shown elsethread, and also the output on my
with my compiler/computer)

Thanks

 

[Keith Thompson]

Richard by the above do you mean that the output of %p is not guaranteed to
be in hexadecimal format?(as shown elsethread, and also the output on my
with my compiler/computer)

Correct; it's not even guaranteed to look anything like a number.

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.

 

[CBFalconer]

Correct; it's not even guaranteed to look anything like a number.

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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[MrG{DRGN}]

Correct; it's not even guaranteed to look anything like a number.

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.

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? Are you still able to
determine the address by somehow deciphering the non-numerical sequence of
printing characters? If not then is there any portable usefulness for %p in
printf? Sorry for all the questions. I'm really pretty new to C, and am self
taught mainly from working with the Quake 2 source code, and some (I found
out after I bought them) obsolete and/or poorly written C programming books.
(Schildt's Teach yourself C, and Oualline's Practical C programming) I don't
have much free cash right now to pickup any better books, but any
suggestions would be welcome, as I should have a bit of non-allotted cash
when my income tax refunds come in. In addition, I want to say I'm sorry if
I've hijacked this thread a bit too much from the original poster!

Thanks

 

[Keith Thompson]

news:[email protected]... [...]
None. You can use it to print a pointer value; how the output is
formatted is entirely up to the implementation.

Richard by the above do you mean that the output of %p is not
guaranteed to be in hexadecimal format?(as shown elsethread, and
also the output on my with my compiler/computer)

Correct; it's not even guaranteed to look anything like a number.

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.

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? Are you still able to
determine the address by somehow deciphering the non-numerical sequence of
printing characters? If not then is there any portable usefulness for %p in
printf?

[...]

Presumably an implementation will display a pointer in whatever format
makes the most sense. On a system with segmented addressing, for
example, "%p" might display something like "dead:beef".

The most important thing to know about pointers is this: Pointers are
not integers. (Read section 4 of the FAQ if you haven't already.)

In addition, I want to say I'm sorry if
I've hijacked this thread a bit too much from the original poster!

No problem; we're still talking about C, which is in improvement over
a lot of threads I've seen here.

 

[Michael Mair]

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? Are you still able to
determine the address by somehow deciphering the non-numerical sequence of
printing characters? If not then is there any portable usefulness for %p in
printf?

You can still use the output as debugging help or to get
unique strings. Or read this address in with sscanf()
(within the usual restrictions).
If you use the address for anything else, you are no longer
in the realm of portable C...
In addition, "physical: 0x1234AFFE virtual: 0xAFFE" or
"data: 0xAFFE"(objects)/"code: 0x1234"(function pointers)
are not strictly numbers but may be more useful...

Cheers
Michael

 

[Jordan Abel]

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.