Whats the use of %p

[Spidey]

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

[Richard Bos]

"Spidey" <am********@gmail.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_Keith) 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 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

[Wojtek Lerch]

"pete" <pf*****@mindspring.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 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]

Wojtek Lerch wrote:

"pete" <pf*****@mindspring.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 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

[Wojtek Lerch]

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

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*****@mindspring.com> wrote in message
news:43**********@mindspring.com...

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]

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?

[Douglas A. Gwyn]

pete wrote:

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.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $6.90 paper, available www.lulu.com

[SM Ryan]

"Malcolm" <re*******@btinternet.com> wrote:
# >
# > 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I love the smell of commerce in the morning.

[MrG{DRGN}]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl...

"Spidey" <am********@gmail.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 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

--
MrG{DRGN}

[Keith Thompson]

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl...

"Spidey" <am********@gmail.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 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.

--
Keith Thompson (The_Other_Keith) 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.

[MrG{DRGN}]

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

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl...

"Spidey" <am********@gmail.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 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? 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
--
MrG{DRGN}

[Keith Thompson]

"MrG{DRGN}" <Ia****@here.com> writes:

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

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl... [...] 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.

--
Keith Thompson (The_Other_Keith) 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.

[Michael Mair]

MrG{DRGN} schrieb:

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

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl...

"Spidey" <am********@gmail.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 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?

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[CBFalconer]

Keith Thompson wrote:

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

"Spidey" <am********@gmail.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 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.

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/>

[Jordan Abel]

On 2006-02-26, CBFalconer <cb********@yahoo.com> wrote:

Keith Thompson wrote:

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
"Spidey" <am********@gmail.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 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.

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.

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-02-26, CBFalconer <cb********@yahoo.com> wrote:

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.

--
Keith Thompson (The_Other_Keith) 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.

[Chris Torek]

In article <%N*******************@twister.nyroc.rr.com>
MrG{DRGN} <Ia****@here.com> wrote:

... 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 "segment:offset" 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").
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[websnarf]

MrG{DRGN} wrote:

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

"MrG{DRGN}" <Ia****@here.com> writes:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:43***************@news.xs4all.nl...
"Spidey" <am********@gmail.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 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?

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

SM Ryan wrote:

"Malcolm" <re*******@btinternet.com> wrote:
# >
# > 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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Ian Malone]

Keith Thompson wrote:

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?

--
imalone

[Michael Mair]

we******@gmail.com schrieb:

SM Ryan wrote:

"Malcolm" <re*******@btinternet.com> wrote:
# >
# > 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?

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

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

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?

--
Keith Thompson (The_Other_Keith) 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.

[P.J. Plauger]

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

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

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]

Keith Thompson wrote:

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

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

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

Keith Thompson wrote:

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

> 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]

--
Keith Thompson (The_Other_Keith) 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.

[MrG{DRGN}]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.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**********@invalid.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 "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.

--
- 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**********@invalid.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 "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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[David Holland]

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

David Holland schrieb:

On 2006-02-27, Michael Mair <Mi**********@invalid.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 "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.

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)