The usage of %p in C

[Tak]

Hi :
I want to know how to use %p in the program.Help me!
Does it mean %x?

[Pietro Cerutti]

Tak wrote:

Hi :
I want to know how to use %p in the program.Help me!
Does it mean %x?

If you mean the printf-style format specifiers, %p is for pointers
types, while %x is for integers types and means "display the integer's
hexadecimal value".

Here's an example:

cat format.c

#include <stdio.h>

int main(void)
{
int i = 10;

printf("dec -%d\n", i);
printf("hex -%x\n", i);
printf("addr -%p\n", &i);

return (0);
}

gcc -Wall -o format format.c && ./format

dec -10
hex -a
addr -0xbfcc4894
--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Richard Bos]

Tak <ka******@gmail.comwrote:

I want to know how to use %p in the program.Help me!

You use %p when you want to print an object pointer. Cast the pointer to
void * and pass it to printf(). Like this:

#include <stdio.h>

int main(void)
{
int object;

printf("The address of object is %p.\n", (void *)&object);

return 0;
}

Does it mean %x?

No. It means %p. It prints a pointer. _How_ that pointer is printed is
system-dependent. Like %x is a possibility. So is (segment like
%4.4X):(offset like %4.4X). So are many other options. It will, in all
likelyhood, depend on how pointers are usually printed on your platform.

Richard

[Richard Heathfield]

Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

[Gilles Chehade]

On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

Richard Heathfield wrote:

>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

>> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

Gilles

--
Booze is the answer. I don't remember the question.

[Mark Bluemel]

Tak wrote:

Hi :
I want to know how to use %p in the program.Help me!

Be more precise in describing your problem and we may be better able to
help.

What problem do you have in using "%p", presumably as a format mask in
printf()?

It's quite simple, it specifies that an argument to printf is a "void *"
and should be formatted as a pointer in an implementation-specific form.

Does it mean %x?

No - %x specifies that an argument is an unsigned int and is to be
formatted in hexadecimal form.

[Mark Bluemel]

Gilles Chehade wrote:

On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

>Richard Heathfield wrote:

>>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);
Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

The point is that it is possible, even if unlikely in most
architectures, for void * to have a different size and/or representation
to, for example, int *.

The %p format mask to printf() specifies that the argument is a void *,
not just "some pointer". If we are trying to be correct, rather than
simply getting away with it on some platform or other, we should pass a
void *.

[Mark Bluemel]

jacob navia wrote:

Richard Heathfield wrote:

>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

>> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

Let's rephrase this. "If you know that int * and void * are represented
in the same way, both size and internal format, on your platform, AND
you never expect to use the code elsewhere, you can skip the cast".

Now for the approach that at least some of us prefer - "the
specification of printf() is that the %p mask indicates that an argument
is a pointer to void, therefore the correct usage is to pass a pointer
to void". This approach means we can write correct code without detailed
knowledge of the internals of the platform, and that code will be portable.

[Richard Heathfield]

Gilles Chehade said:

On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

>Richard Heathfield wrote:

>>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

Any object pointer can be converted to and from void * without loss of
information. The cast is required; in its absence, the behaviour is
undefined. I do not dispute that Mr Navia thinks the cast to be
unnecessary unless int * and void * are different sizes but, regardless of
his thoughts on the matter, the cast remains necessary. The proof is in
three parts, the first of which is in 7.19.6.1, in the definition of
fprintf:

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

The second part of the proof is in 7.19.6.3, the definition of printf:

2 The printf function is equivalent to fprintf with the argument stdout
interposed before the arguments to printf.

The third is in 4.2:

2 If a ``shall'' or ``shall not'' requirement that appears outside of a
constraint is violated, the behavior is undefined.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Denis Kasak]

jacob navia wrote:

Richard Heathfield wrote:

>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

>> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

The cast is necessary because it is required by the Standard.

The most obvious practical reason for this necessity may well be the one
you mention (sizes of pointers to different types differ), but that is
irrelevant. The cast should be there precisely to avoid worrying about that.

--
Denis Kasak

Numbers in email addresses are so passé.

[Gilles Chehade]

On 2007-09-25, Mark Bluemel <ma**********@pobox.comwrote:

Gilles Chehade wrote:

>On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Heathfield wrote:
Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);
Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

The point is that it is possible, even if unlikely in most
architectures, for void * to have a different size and/or representation
to, for example, int *.

The %p format mask to printf() specifies that the argument is a void *,
not just "some pointer". If we are trying to be correct, rather than
simply getting away with it on some platform or other, we should pass a
void *.

Thanks,

Gilles

--
Booze is the answer. I don't remember the question.

[Gilles Chehade]

On 2007-09-25, Richard Heathfield <rj*@see.sig.invalidwrote:

Gilles Chehade said:

>On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Heathfield wrote:
Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);
I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

Any object pointer can be converted to and from void * without loss of
information. The cast is required; in its absence, the behaviour is
undefined. I do not dispute that Mr Navia thinks the cast to be
unnecessary unless int * and void * are different sizes but, regardless of
his thoughts on the matter, the cast remains necessary. The proof is in
three parts, the first of which is in 7.19.6.1, in the definition of
fprintf:

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

The second part of the proof is in 7.19.6.3, the definition of printf:

2 The printf function is equivalent to fprintf with the argument stdout
interposed before the arguments to printf.

The third is in 4.2:

2 If a ``shall'' or ``shall not'' requirement that appears outside of a
constraint is violated, the behavior is undefined.

Thanks,

Gilles

--
Booze is the answer. I don't remember the question.

[Pietro Cerutti]

Mark Bluemel wrote:

Gilles Chehade wrote:

>On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Heathfield wrote:
Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);
Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

The point is that it is possible, even if unlikely in most
architectures, for void * to have a different size and/or representation
to, for example, int *.

The %p format mask to printf() specifies that the argument is a void *,
not just "some pointer". If we are trying to be correct, rather than
simply getting away with it on some platform or other, we should pass a
void *.

The correction is correct ;-)

Anyway, a question raises:

1) two pointer types are allowed to be of different sizes
2) the void pointer is guaranteed to store any other pointer's value
without loss of information
this leads to:
3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

if 3) is a correct deduction, then I don't see the point to impose that
an argument of printf used in conjunction with %p must be a void pointer.

if 3) is incorrect, how do we assure that a conversion to void * cannot
lead to a loss of information?

Thanks for clarifying this point.

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp

[Mark Bluemel]

Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

2) the void pointer is guaranteed to store any other pointer's value
without loss of information
this leads to:

3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

Not necessarily. I used to work on a machine which had 32-bit and 48-bit
pointers which both actually had the same effective "precision". Both
actually addressed bytes in a 32-bit address space. Don't ask...

if 3) is a correct deduction, then I don't see the point to impose that
an argument of printf used in conjunction with %p must be a void pointer.

All printf can go on is the data you gave it. By giving a "%p" mask
you've said you are passing a void * pointer. Because this is a variadic
function, there will be no safety net provided by the compiler - nothing
will ensure that what you pass will be converted to a void *.

If you pass printf() something else, like an int *, you invoke undefined
behaviour. As ever, UB may turn out to do what you want, but it is not
guaranteed.

if 3) is incorrect, how do we assure that a conversion to void * cannot
lead to a loss of information?

That's the implementer's problem, not ours :-)

[Richard]

Mark Bluemel <ma**********@pobox.comwrites:

Pietro Cerutti wrote:

>... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

[Christopher Benson-Manica]

[comp.lang.c] jacob navia <ja***@jacob.remcomp.frwrote:

Richard Heathfield wrote:

> printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

if( sizeof(void*) != sizeof(int*) ) {
printf("addr -%p\n", (void *)&i);
}
else {
printf("addr -%p\n", &i);
}

Even given such "unwarranted chumminess with the implementation"
(which as has been noted elsethread is still not enough to guarantee
that the else clause will not break), doesn't this strike you as a
bit silly? Why not just use the cast?

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.

[Richard Bos]

Richard <rg****@gmail.comwrote:

Mark Bluemel <ma**********@pobox.comwrites:

Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

Who was talking about malloc()ed blocks of memory? We were talking about
void *s and int *s. They can certainly be laid out differently in
memory, as long as converting from one to the other and back works.
Note: converting. Not reinterpreting the bit patterns. IOW,

int i, *int_ptr=&i;
void *void_ptr=int_ptr;
int *int_ptr2=void_ptr;

must work, and int_ptr2 must compare equal to int_ptr. This is because
the types of int_ptr, int_ptr2 and void_ptr are all known to the
compiler at the point of conversion.
This is not the case with pointers passed to variadic functions. A
variadic function does _not_ know that it has been passed an int *
instead of the void * it has been told to expect, and what's worse, it
has no way to find out. Therefore, when a variadic function - in this
case, printf() - believes that it needs a void *, it will try to read a
void *, and not an int *. No conversion takes place.

Richard

[Richard]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Richard <rg****@gmail.comwrote:

>Mark Bluemel <ma**********@pobox.comwrites:

Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

Who was talking about malloc()ed blocks of memory? We were talking
about

I was. A question if you will.

I'm a bit hazy at the moment but I remember someone harping on about
pointers of one type being of a special type and residing in "special
memory". I suspect it comes out in the wash in that the compiler could
"convert" the "normal storage" to "special" storage unbeknown to the
program.

Then again, I could be meandering too much. I just had a peek
at Facebook. Shockingly crass.

void *s and int *s. They can certainly be laid out differently in
memory, as long as converting from one to the other and back works.
Note: converting. Not reinterpreting the bit patterns. IOW,

int i, *int_ptr=&i;
void *void_ptr=int_ptr;
int *int_ptr2=void_ptr;

must work, and int_ptr2 must compare equal to int_ptr. This is because
the types of int_ptr, int_ptr2 and void_ptr are all known to the
compiler at the point of conversion.

Fair enough.

This is not the case with pointers passed to variadic functions. A
variadic function does _not_ know that it has been passed an int *
instead of the void * it has been told to expect, and what's worse, it
has no way to find out. Therefore, when a variadic function - in this
case, printf() - believes that it needs a void *, it will try to read a
void *, and not an int *. No conversion takes place.

Yes, I understand that. variadic functions weren't really the issue to
my question or pondering.

[Richard Tobin]

In article <fd**********@aioe.org>,
Mark Bluemel <ma**********@pobox.comwrote:

>>I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

>even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

>The point is that it is possible, even if unlikely in most
architectures, for void * to have a different size and/or representation
to, for example, int *.

Even this would not usually be a problem: provided there was a
function prototype in scope the pointer would be converted to void *.
You can perfectly well give an int * argument to free(), for example.
Unfortunately, because printf() is a variadic function, the compiler
can't tell what type is going to be expected, so it can't do the
conversion.

Some compilers do have special knowledge of printf(). Gcc in this
case gives a warning:

warning: format '%p' expects type 'void *', but argument 2 has type 'int *'

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Jack Klein]

On Tue, 25 Sep 2007 15:49:04 +0200, jacob navia
<ja***@jacob.remcomp.frwrote in comp.lang.c:

Richard Heathfield wrote:

Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

Actually there could be conforming implementations where this code
could fail even if both pointer types have the same size. I think I
might actually have used one, a quarter century or so ago, but I can't
remember for sure.

Same size does not necessarily guarantee passing and/or returning in
the same manner (same register, same stack location, same memory
block, whatever).

Not quite the same thing, I do remember compilers for the Motorola
68000 series (old Apple, Atari, Amiga computers) that would return
integer types in a specific D register, pointers in one of the A
registers.

So failure to include a prototype for malloc() and using the cast:

char *cp = (char *)malloc(some_size);

....would result in the pointer being initialized with some totally
untreated value from a data register, completely ignoring the actual
pointer in an address register.

The point is, passing anything other than pointer to void to printf()
to match a "%p" conversion specifier is undefined behavior. Even if
it works on most compilers. Even if it works on all the compilers you
have tried it on.

There are reasons to write a program that uses implementation-defined,
and even technically undefined behavior, if you know what your
implementation does with them. Feeling like you can't be bothered to
write the "(void *)" cast in one of the few situations in C where such
a cast is not necessary is not one of the valid reasons.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Jack Klein]

On Tue, 25 Sep 2007 16:48:20 +0200, Pietro Cerutti
<gahr_AT_gahr_DOT_ch_DO_NOT_SPAMwrote in comp.lang.c:

Mark Bluemel wrote:

Gilles Chehade wrote:

On 2007-09-25, jacob navia <ja***@jacob.remcomp.frwrote:
Richard Heathfield wrote:
Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

printf("addr -%p\n", &i);
Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

even if they were, a void * isn't supposed to be able to store
a value held by another pointer of any kind ?

The point is that it is possible, even if unlikely in most
architectures, for void * to have a different size and/or representation
to, for example, int *.

The %p format mask to printf() specifies that the argument is a void *,
not just "some pointer". If we are trying to be correct, rather than
simply getting away with it on some platform or other, we should pass a
void *.

The correction is correct ;-)

Anyway, a question raises:

1) two pointer types are allowed to be of different sizes

Yes, that is correct.

2) the void pointer is guaranteed to store any other pointer's value
without loss of information

Well, that is almost correct. There is a guarantee with pointer to
void with respect to pointer to any object type. There is no
correspondence, defined conversion, or any other guarantee between
pointers to objects and pointers to functions.

Here is what the standard says:

"A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object type
may be converted to a pointer to void and back again; the result shall
compare equal to the original pointer."

this leads to:
3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

If you read the quotation from the standard above, you will note that
it requires that pointer to void be able to hold all the useful
information from any other pointer to object type. A perverse
implementation could have pointers to void and character types
actually occupy less space than pointers to other object types,
although those larger pointers to other types could not use more bits.

if 3) is a correct deduction, then I don't see the point to impose that
an argument of printf used in conjunction with %p must be a void pointer.

There is nothing that requires that a compiler pass pointer to void
and, for example, pointer to int, in the same manner to functions.
printf() is a variadic function, where there is no prototype to tell
the compiler to convert the parameters, if necessary.

What happens if a particular compiler passes pointer to void in
register R3 and pointer to int in register R5?

Mainly, it is undefined behavior because the C standard says that it
is.

if 3) is incorrect, how do we assure that a conversion to void * cannot
lead to a loss of information?

Again, 3) is not necessarily correct. A compiler for a platform with
a 32-bit address space could have 32 bit pointers to void, and 64 bit
pointers to int, although it could only use 32 bits of the pointer to
int.

Thanks for clarifying this point.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Chris Torek]

In article <46**********************@news.sunrise.ch>
Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMwrote:

>1) two pointer types are allowed to be of different sizes
2) the void pointer is guaranteed to store any other pointer's value
without loss of information

Any "data pointer", anyway. (That is, "void *" might not be able
to hold a pointer-to-function type. This is the case in some MS-DOS
compiler models, for instance, when functions use 32-bit addresses
and "data bytes" live in a 16-bit address space.)

>this leads to:
3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

Not necessarily -- it just means that "void *" values have enough
data to *reconstruct* any *valid* data pointer.

Imagine, for instance, that for some reason "int *" uses a megabyte,
but only 39 bits of that megabyte really specify the actual memory
address. Then "void *" might fit in a 21-byte object, with 39 bits
of those 29 bytes holding the "important" 39 bits of the "int *".
Note that a different subset of the "void *" bits might hold the
"important" bits of "short *", and so on.

(On Real Machines, of course, there are only three or four actual
pointer formats, typically 4, 8, and 16 or so bytes each.)

>if 3) is a correct deduction, then I don't see the point to impose that
an argument of printf used in conjunction with %p must be a void pointer.

Perhaps "int *" values are passed in red registers, and "void *"
values in blue registers. (Most integers go in green registers.
Yellow registers are for float, purple for double, and the black
registers are reserved to the secret part of the system. :-) )

>if 3) is incorrect, how do we assure that a conversion to void * cannot
lead to a loss of information?

This is up to the implementation -- the C Standard requires that
the implementation achieve it *somehow*, though.
--
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.

[Stephen Sprunk]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46**********************@news.orange.fr...

Richard Heathfield wrote:

>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

>> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

Without the cast it's UB, period. If it happens to do what the programmer
expects on systems where sizeof(int*) == sizeof(void*), that's one possible
result of UB.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Kenneth Brody]

Richard wrote:

>
Mark Bluemel <ma**********@pobox.comwrites:

Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

No need to get malloc() and friends involved.

Consider:

char *;
and
char (*)(char);

One points to a char, the other to a function that takes and returns
a char. One points to data, the other to code. Who says that the
way you point to data has any relation to how you point to code?

First, you have the simple case of segmented memory architecture,
where you may have 32-bit code pointers and 48-bit data pointers.

Next, there are cases where the pointers may be the same size, but
formatted differently. I once worked on a platform with 36-bit
words and 18-bit addresses. Within a 36-bit word, you could hold
a "pointer" to bits within an address. (ie: 18 bits for address,
plus additional bits to point within the 36-bit value stored there.)
While I never used a C compiler on that system, it is quite
possible that a pointer to code would be a straight 18-bit value,
with the other bits ignored, while a pointer to data would be the
18-bit address plus the additional bits to point within the data.
And yet, they would both be 36 bit values.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Mark McIntyre]

On Tue, 25 Sep 2007 15:49:04 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Richard Heathfield wrote:

>Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAMsaid:

<snip>

>> printf("addr -%p\n", &i);

Undefined behaviour. Use this instead:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

In fact the cast is strictly speaking *required*, precisely _because_
you cannot guarantee that pointer sizes are the same.

Obviously if you don't need to worry about portability and never
expect to get a new compiler or OS, then....
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Tue, 25 Sep 2007 11:47:23 -0500, in comp.lang.c , Jack Klein
<ja*******@spamcop.netwrote:

>Actually there could be conforming implementations where this code
could fail even if both pointer types have the same size. I think I
might actually have used one, a quarter century or so ago, but I can't
remember for sure.

You're probably thinking of MacOS or possibly TOS, where different
types sometimes got passed in different registers.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Richard <rg****@gmail.comwrites:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

>Richard <rg****@gmail.comwrote:

>>Mark Bluemel <ma**********@pobox.comwrites:
Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

Who was talking about malloc()ed blocks of memory? We were talking
about

I was. A question if you will.

I'm a bit hazy at the moment but I remember someone harping on about
pointers of one type being of a special type and residing in "special
memory". I suspect it comes out in the wash in that the compiler could
"convert" the "normal storage" to "special" storage unbeknown to the
program.

[...]

Different pointer types can have different representations, but
malloc()ed memory can hold objects of any type. A conforming
implementation can't restrict certain types of objects to be stored
only in certain memory regions. (If such "special" objects are to be
provided, the implementation can provide access to them, but not as
ordinary C objects; there might be a compiler extension.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <nc********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

>In fact the cast is strictly speaking *required*, precisely _because_
you cannot guarantee that pointer sizes are the same.

I think that even if the pointer sizes are the same, and they have
the same representation, nothing stops an implementation from passing
int * and void * pointers to variadic functions in different ways.

In fact, I don't see anything that stops it from passing void * and char *
in different ways, which seems like a defect to me.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Tue, 25 Sep 2007 20:11:37 +0000, Richard Tobin wrote:

In article <nc********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.netwrote:

>>>I think the cast is unnecessary, unless int * and void * are of
different sizes in your system...

>>In fact the cast is strictly speaking *required*, precisely _because_
you cannot guarantee that pointer sizes are the same.

I think that even if the pointer sizes are the same, and they have the
same representation, nothing stops an implementation from passing int *
and void * pointers to variadic functions in different ways.

In fact, I don't see anything that stops it from passing void * and char
* in different ways, which seems like a defect to me.

void * and char * may be passed in different ways if and only if va_arg
can still be used to access either as the other. If you use it to access
a void * argument as were it a char *, or vice versa, you get the same
value. There's a special exception in the definition of va_arg that makes
this so.

But yes, for printf you have to get the type right, since it need not be
implemented using va_arg.

[Army1987]

On Tue, 25 Sep 2007 13:44:32 +0000, Richard Bos wrote:

Tak <ka******@gmail.comwrote:

>I want to know how to use %p in the program.Help me!

[snip]

>Does it mean %x?

No. It means %p. It prints a pointer. _How_ that pointer is printed is
system-dependent. Like %x is a possibility. So is (segment like
%4.4X):(offset like %4.4X). So are many other options. It will, in all
likelyhood, depend on how pointers are usually printed on your platform.

What am I missing which causes the last sentence not to be a
tautology, so that "in all likelyhood" is needed instead of
"obviously"?

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Army1987]

On Tue, 25 Sep 2007 11:47:23 -0500, Jack Klein wrote:

There are reasons to write a program that uses implementation-defined,
and even technically undefined behavior, if you know what your
implementation does with them. Feeling like you can't be bothered to
write the "(void *)" cast in one of the few situations in C where such
a cast is not necessary is not one of the valid reasons.

You meant "...a cast is necessary..."?
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

On Tue, 25 Sep 2007 13:44:32 +0000, Richard Bos wrote:

>Tak <ka******@gmail.comwrote:

>>I want to know how to use %p in the program.Help me!

[snip]

>>Does it mean %x?

No. It means %p. It prints a pointer. _How_ that pointer is printed is
system-dependent. Like %x is a possibility. So is (segment like
%4.4X):(offset like %4.4X). So are many other options. It will, in all
likelyhood, depend on how pointers are usually printed on your platform.

What am I missing which causes the last sentence not to be a
tautology, so that "in all likelyhood" is needed instead of
"obviously"?

It depends on the meaning of "platform". It's possible, for example,
that an operating system might have a convention of printing pointers
in octal, but a C implementation running on that OS might print them
in hexadecimal.

If "platform" is synonymous with "implementation", then yes, it's a
tautology.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Old Wolf]

On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:

int i = 10;

printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

[Keith Thompson]

Old Wolf <ol*****@inspire.net.nzwrites:

On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:

> int i = 10;

printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

On the other hand, even on a DS9000 the following:

printf("hex -%x\n", (unsigned)i);

will work properly (unless there's an I/O error).

If you're writing new code, it's easier to use exactly the right type
in the first place than to prove that it's ok to use a slightly
different type.

But if you see the above in somebody else's program that isn't
working, it should be safe to look elsewhere for the source of the
bug.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Bos]

Jack Klein <ja*******@spamcop.netwrote:

[ Snip! ]

On Tue, 25 Sep 2007 16:48:20 +0200, Pietro Cerutti
<gahr_AT_gahr_DOT_ch_DO_NOT_SPAMwrote in comp.lang.c:

2) the void pointer is guaranteed to store any other pointer's value
without loss of information

Well, that is almost correct. There is a guarantee with pointer to
void with respect to pointer to any object type. There is no
correspondence, defined conversion, or any other guarantee between
pointers to objects and pointers to functions.

Here is what the standard says:

"A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object type
may be converted to a pointer to void and back again; the result shall
compare equal to the original pointer."

this leads to:
3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

If you read the quotation from the standard above, you will note that
it requires that pointer to void be able to hold all the useful
information from any other pointer to object type. A perverse
implementation could have pointers to void and character types
actually occupy less space than pointers to other object types,
although those larger pointers to other types could not use more bits.

Yes, they could; but those extra bits could not be used to hold required
information, and a comparison of pointers that are equal, except that
one has information in the extra bits and the other lost that extra
information in passing through a void * and back, must compare equal.
Two pointers which both have information in the extra bits are still
allowed to compare different, AFAICT. (One reason for doing this is to
provide debugging information. It may not be a _good_ reason to do so
for normal pointers, but not for void * and char *; but it is a legal
one.)

Richard

[Michal Nazarewicz]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Jack Klein <ja*******@spamcop.netwrote:

[ Snip! ]

>On Tue, 25 Sep 2007 16:48:20 +0200, Pietro Cerutti
<gahr_AT_gahr_DOT_ch_DO_NOT_SPAMwrote in comp.lang.c:

2) the void pointer is guaranteed to store any other pointer's value
without loss of information

Well, that is almost correct. There is a guarantee with pointer to
void with respect to pointer to any object type. There is no
correspondence, defined conversion, or any other guarantee between
pointers to objects and pointers to functions.

Here is what the standard says:

"A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or object type
may be converted to a pointer to void and back again; the result shall
compare equal to the original pointer."

this leads to:
3) the size of a void pointer is guaranteed to be at least as big as the
size of any other pointers

If you read the quotation from the standard above, you will note that
it requires that pointer to void be able to hold all the useful
information from any other pointer to object type. A perverse
implementation could have pointers to void and character types
actually occupy less space than pointers to other object types,
although those larger pointers to other types could not use more bits.

Yes, they could; but those extra bits could not be used to hold required
information, and a comparison of pointers that are equal, except that
one has information in the extra bits and the other lost that extra
information in passing through a void * and back, must compare equal.
Two pointers which both have information in the extra bits are still
allowed to compare different, AFAICT.

No, they are not. The same way as integers with different padding bits
but the same value bits are required to compare equal.

(One reason for doing this is to provide debugging information. It may
not be a _good_ reason to do so for normal pointers, but not for void
* and char *; but it is a legal one.)

If some debug information were stored in those padding bits
implementation would be forced to ignore them when comparing pointers.
(Well, it is possible to create a pointer where those extra bits store
some kind of CRC in which case implementation could use it while
comparing pointers.)

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[Army1987]

On Tue, 25 Sep 2007 16:46:23 -0700, Keith Thompson wrote:

On the other hand, even on a DS9000 the following:

printf("hex -%x\n", (unsigned)i);

will work properly (unless there's an I/O error).

<nitpick>
If there's an I/O error it will return a negative value, which is
the proper behavior in that case.
</nitpick>
:-)

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Charlie Gordon]

"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@d55g2000hsg.googlegroups. com...

On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:

> int i = 10;

printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

--
Chqrlie.

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

On Tue, 25 Sep 2007 16:46:23 -0700, Keith Thompson wrote:

>On the other hand, even on a DS9000 the following:
printf("hex -%x\n", (unsigned)i);

will work properly (unless there's an I/O error).

<nitpick>
If there's an I/O error it will return a negative value, which is
the proper behavior in that case.
</nitpick>
:-)

Touche.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@d55g2000hsg.googlegroups. com...

>On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:

>> int i = 10;

printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

The standard requires signed int and unsigned int to have the same
size and alignment, and for values representable in both to have the
same representation. But I don't think the standard requires the same
parameter passing method for both.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Martin Wells]

jacob:

printf("addr -%p\n", (void *)&i);

I think the cast is unnecessary, unless int * and void *
are of different sizes in your system...

Here's a case of where you can add NO overhead to your program and at
the same time maintain its portability... YET you still strive to
deportify your programs as best you can. You should start writing
4294967295 instead of UINT_MAX, that'll further your cause even
further.

It's strange to see how someone could be so hellbent on causing
inconvenience for themselves.

Martin

[Old Wolf]

On Sep 27, 4:37 am, "Charlie Gordon" <[e-mail]:

"Old Wolf" <[e-mail]:

Pietro Cerutti wrote:

int i = 10;
printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

Because the standard explicitly says that the argument
corresponding to %x must be of type 'unsigned int'. The
DS9K compiler could note that you pass a signed int,
and replace the code with a call to nasal_demon().

[Jack Klein]

On Tue, 25 Sep 2007 23:40:16 +0200, Army1987 <ar******@NOSPAM.it>
wrote in comp.lang.c:

On Tue, 25 Sep 2007 11:47:23 -0500, Jack Klein wrote:

There are reasons to write a program that uses implementation-defined,
and even technically undefined behavior, if you know what your
implementation does with them. Feeling like you can't be bothered to
write the "(void *)" cast in one of the few situations in C where such
a cast is not necessary is not one of the valid reasons.

You meant "...a cast is necessary..."?

Yes, indeedy! But I didn't charge for the extra word...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Richard Bos]

Richard <rg****@gmail.comwrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Richard <rg****@gmail.comwrote:

Mark Bluemel <ma**********@pobox.comwrites:

Pietro Cerutti wrote:

... a question raises:

1) two pointer types are allowed to be of different sizes

And formats...

I keep hearing this. Can you explain how,say, a "special" pointer can be
stored in a malloc'ed block of memory which basically returns a single
block from a common memory pool?

Who was talking about malloc()ed blocks of memory? We were talking
about

I was. A question if you will.

I'm a bit hazy at the moment but I remember someone harping on about
pointers of one type being of a special type and residing in "special
memory".

That is, effectively, not possible. (To be precise, if it is possible,
it must be invisible to any conforming program, for the reason you
mention above amongst others.) However, it has nothing whatsoever to do
with pointers passed to variadic functions, so I fail to see why you
appended that question to this thread.

Richard

[Charlie Gordon]

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

"Charlie Gordon" <ne**@chqrlie.orgwrites:

>"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@d55g2000hsg.googlegroups. com...

>>On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:
int i = 10;

printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

The standard requires signed int and unsigned int to have the same
size and alignment, and for values representable in both to have the
same representation. But I don't think the standard requires the same
parameter passing method for both.

Even for varadic functions ?

--
Chqrlie.

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Fri, 28 Sep 2007 16:12:05 +0200, Charlie Gordon wrote:

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@d55g2000hsg.googlegroups. com...
On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:
int i = 10;
>
printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this causes undefined
behaviour. The standard specifies that %x requires an unsigned int
argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

The standard requires signed int and unsigned int to have the same size
and alignment, and for values representable in both to have the same
representation. But I don't think the standard requires the same
parameter passing method for both.

Even for varadic functions ?

The standard requires this program to work:

#include <stdio.h>
#include <stdarg.h>

void f(int a, ...) {
va_list ap;
va_start(ap, a);
printf("%d %d\n", a, va_arg(ap, int));
va_end(ap);
}

int main(void) {
unsigned x = 1;
f(x, x);
return 0;
}

The implementation must ensure an int value 1 is read even though an
unsigned int value 1 is passed. However, so long as va_arg can find the
right value in either case, the standard allows an int and an unsigned
int to be passed differently (possibly by passing argument type
information along with argument values). And there's nothing requiring
the same va_arg handling from the *printf functions.

[Keith Thompson]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

>"Charlie Gordon" <ne**@chqrlie.orgwrites:

>>"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@d55g2000hsg.googlegroups. com...
On Sep 26, 1:38 am, Pietro Cerutti <gahr_AT_gahr_DOT_ch_DO_NOT_SPAM>
wrote:
int i = 10;
>
printf("hex -%x\n", i);

It could be argued (and has been, in fact) that this
causes undefined behaviour. The standard specifies that
%x requires an unsigned int argument.

I can't see anything other than a DS9000 failing it, though.

How could that be a problem, even on a DS9K ?

The standard requires signed int and unsigned int to have the same
size and alignment, and for values representable in both to have the
same representation. But I don't think the standard requires the same
parameter passing method for both.

Even for varadic functions ?

Whoops you're right. C99 7.15.1.1p2 requires corresponding signed and
unsigned to work properly for values that are representable in both
(it also requires void* and pointers to character types to be
compatible).

As Harald points out, printf isn't required to use va_arg. But the
DS9K is probably the only implementation where the above would fail
(and it took a fair amount of work to cause that case to fail without
breaking conformance).

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"