«

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

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

"Spidey" <> 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" <> 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_Keith) kst- <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.

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?

--
pete

"pete" <> wrote in message
news:...
> 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?

Wojtek Lerch wrote:
>
> "pete" <> wrote in message
> news:...
> > 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?

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

"pete" <> wrote in message
news:...
> 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).

Wojtek Lerch wrote:
>
> "pete" <> wrote in message
> news:...
> > 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(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.

--
pete

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?