Whats the use of %p

[Spidey]

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

[Richard Bos]

"Spidey" <am********@gma il.com> wrote:

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

[Roka]

Spidey wrote:

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

[Keith Thompson]

"Roka" <Ro*****@gmail. com> writes:

Spidey wrote:

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

"%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);

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[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 interchangabili ty.

C99
6.2.5 Types
31)The same representation and alignment requirements are
meant to imply interchangeabil ity as arguments to
functions, return values from functions, and members of
unions.
39)The same representation and alignment requirements are
meant to imply interchangeabil ity 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 interchangeabil ity?

--
pete

[Wojtek Lerch]

"pete" <pf*****@mindsp ring.com> wrote in message
news:43******** ***@mindspring. com...

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

C99
6.2.5 Types
31)The same representation and alignment requirements are
meant to imply interchangeabil ity as arguments to
functions, return values from functions, and members of
unions.
39)The same representation and alignment requirements are
meant to imply interchangeabil ity 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 interchangeabil ity?

Because it would then have to explain, in detail, what situations the
interchangeabil ity 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 interchangeabil ity as return values from function? I haven't
: found any normative text that implies this kind of interchangeabil ity;
which
: of the above three situations are meant to apply if T1 and T2 have
different
: return types?

[pete]

Wojtek Lerch wrote:

"pete" <pf*****@mindsp ring.com> wrote in message
news:43******** ***@mindspring. com...

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

C99
6.2.5 Types
31)The same representation and alignment requirements are
meant to imply interchangeabil ity as arguments to
functions, return values from functions, and members of
unions.
39)The same representation and alignment requirements are
meant to imply interchangeabil ity 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 interchangeabil ity?

Because it would then have to explain, in detail, what situations the
interchangeabil ity 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 interchangeabil ity as return values from function? I haven't
: found any normative text that implies this kind of interchangeabil ity;
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 */

--
pete

[Wojtek Lerch]

"pete" <pf*****@mindsp ring.com> wrote in message
news:43******** **@mindspring.c om...

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]

Wojtek Lerch wrote:

"pete" <pf*****@mindsp ring.com> wrote in message
news:43******** **@mindspring.c om...

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,

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

void part_fprint(FIL E *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.

--
pete

[Wojtek Lerch]

Wojtek Lerch wrote:

: - it's OK to define the function as T1 and then as T2 in *the same* ^^^^^^
I meant "declare", of course. :-) : translation unit, even though 6.7p4 says it's a constraint violation?