Printing a NULL pointer

[junky_fellow]

Consider an implementation that doesn't use all bits 0 to represent
a NULL pointer. Let the NULL pointer is represented by 0x12345678.
On such an implementation, if the value of NULL pointer is printed
will it be all 0's or 0x12345678

int main(void)
{

char *ptr;
ptr = 0;

printf("\nptr=% p\n",ptr);
}

What would be the output, 0 or 0x12345678 ?
I think user must be kept transparent from the internal representation
of NULL pointer. Even if the implementation is
using 0x12345678 for NULL pointer, value printed should be all
bits zero.

[Richard Tobin]

In article <pa************ *************** *@netactive.co. uk>,
Lawrence Kirby <lk****@netacti ve.co.uk> wrote:

In all real-world implementations the NULL pointer is all-bits zero.
(Someone will post a counter-example if I'm wrong.)

See FAQ 5.17

Thanks, an interesting list. But I don't think any of the machines
listed as having non-zero null pointers are in the real world any
more. In the case of the Primes, I certainly hope not.

-- Richard

[pete]

Anonymous 7843 wrote:

And how the heck do you print a function pointer? It's not
guaranteed to fit in a void*, right?

Right.

--
pete

[Dik T. Winter]

In article <133se.63$SF5.2 6@fed1read07> an******@exampl e.com writes:

In article <20050615162631 16807%clarkcox3 @gmailcom>,
Clark S. Cox III <cl*******@gmai l.com> wrote:

On 2005-06-15 14:07:30 -0400, an******@exampl e.com (Anonymous 7843) said:

.... But you know how %d will printf and how it will scanf back
in. You know that you can use spaces, letters, or
punctuation to separate a %d-generated number from other
data. You do *not* know (from the standard) what %p will or
won't print so you don't know what delimiters, if any, are
safe to use. So, you can't use delimiters.
You can. You are sure (from the standard) that the output will not include
\t, \r or \n. %p is guaranteed to give only printable characters, and those
three are not; they are control characters. However I always doubted the
usefulness of being able to read pointers with %p, except, perhaps, in
debuggers.
And how the heck do you print a function pointer? It's not
guaranteed to fit in a void*, right?

There is a good reason for that. There are systems where function pointers
simply are not compatible with data pointers. For example, when they are
much wider. But what is a good reason to print a function pointer?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Neil Kurzman]

ju**********@ya hoo.co.in wrote:

Lawrence Kirby wrote:

On Tue, 14 Jun 2005 22:50:26 -0700, junky_fellow wrote:

Consider an implementation that doesn't use all bits 0 to represent
a NULL pointer. Let the NULL pointer is represented by 0x12345678.
On such an implementation, if the value of NULL pointer is printed
will it be all 0's or 0x12345678

Either or neither. The implementation could coose to output it as, for
example, <null>

int main(void)
{

char *ptr;
ptr = 0;

printf("\nptr=% p\n",ptr);
}
}
What would be the output, 0 or 0x12345678 ?

The standard does not specify the form of output of %p. There is no
requirement that it takes the form of a hex number, although it can and
some implementations do that.

I think user must be kept
transparent from the internal representation of NULL pointer.

That is certainly not a requirement. All that is required is that scanf()
%p can recreate the pointer from the output of printf() %p

Even if
the implementation is using 0x12345678 for NULL pointer, value printed
should be all bits zero.

If you want full transparency then direct correspondance to any particular
bit pattern should be avoided.

Lawrence

Is there any way by which user can determine what is the internal
representation for a NULL pointer ? I am asking this because,
sometimes during debugging the memory dump is analysed. In that
case it would be difficult to find it is a NULL pointer or not.

Set a Pointer to NULL then look at the memory dump.
Theoretical vs Practical.

[Michael Wojcik]

In article <ln************ @nuthaus.mib.or g>, Keith Thompson <ks***@mib.or g> writes:

ju**********@ya hoo.co.in writes:
[...]

Is there any way by which user can determine what is the internal
representation for a NULL pointer ? I am asking this because,
sometimes during debugging the memory dump is analysed. In that
case it would be difficult to find it is a NULL pointer or not.
printf("%p\n", (void*)NULL);

is very likely to print a legible form of the representation of a null
pointer (which is very likely to be all-bits-zero).

Though not on the ever-lovin' AS/400.[1] This example also shows
that the %p format on the AS/400 contains both colons and spaces,
and so meets the fears of some other posters in this thread.

(On the other hand, I ran across a post from Dan Pop noting that
length and precision specifiers are not permitted with %p; if true,
that satisfies one worry that's been posted.)
If "very likely"
isn't good enough, several followups have shown how to break the
representation down into a sequence of bytes.

Yep. 16 bytes, in the case of the '400. The '400 also offers a
cozy 2**127-1 pointer trap representations , though - mirabile dictu -
its null pointer representation is all-bits-zero.
1. http://groups-beta.google.com/group/...4a3c0c955d17f3

See also:
http://groups-beta.google.com/group/...438cf53aa68a6b
http://groups-beta.google.com/group/...9b7dc93bdbf187

--
Michael Wojcik mi************@ microfocus.com

The surface of the word "profession " is hard and rough, the inside mixed with
poison. It's this that prevents me crossing over. And what is there on the
other side? Only what people longingly refer to as "the other side".
-- Tawada Yoko (trans. Margaret Mitsutani)

[Lawrence Kirby]

On Thu, 16 Jun 2005 15:33:24 +0000, Michael Wojcik wrote:

....

(On the other hand, I ran across a post from Dan Pop noting that
length and precision specifiers are not permitted with %p; if true,
that satisfies one worry that's been posted.)

A precision specifier is certainly not permitted with %p (it givbes
undefined behaviour) but as far as I can see minimum field width is.
The only conversion specifier you can't use a minimum field width
for is %%.

Lawrence

[Anonymous 7843]

In article <II********@cwi .nl>, Dik T. Winter <Di********@cwi .nl> wrote:

But what is a good reason to print a function pointer?

Depends on your definition of good, but how about
debugging a non-portable feature like dynamic libraries?

Technically there is no need to be able to print object pointers
either, yet we can do so.
--
7842++

[Jean-Claude Arbaut]

Le 17/06/2005 02:12, dans aAose.225$SF5.2 14@fed1read07, «*Anonymous 7843*»
<an******@examp le.com> a écrit*:

In article <II********@cwi .nl>, Dik T. Winter <Di********@cwi .nl> wrote:

But what is a good reason to print a function pointer?

Depends on your definition of good, but how about
debugging a non-portable feature like dynamic libraries?

Technically there is no need to be able to print object pointers
either, yet we can do so.

Is there a good reason appart from debugging ? I can't see one, but
I may be too tired at 3:15 local :-)

[Dik T. Winter]

In article <aAose.225$SF5. 214@fed1read07> an******@exampl e.com writes:

In article <II********@cwi .nl>, Dik T. Winter <Di********@cwi .nl> wrote:

But what is a good reason to print a function pointer?

Depends on your definition of good, but how about
debugging a non-portable feature like dynamic libraries?

But what do you think is a good way to print a function pointer when it
is, say, twice as wide as an object pointer? While, in general, object
pointers are as wide, or smaller than a void*, a function pointer can
be much wider.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Keith Thompson]

"Dik T. Winter" <Di********@cwi .nl> writes:

In article <aAose.225$SF5. 214@fed1read07> an******@exampl e.com writes:

> In article <II********@cwi .nl>, Dik T. Winter <Di********@cwi .nl> wrote:

> > But what is a good reason to print a function pointer?

>
> Depends on your definition of good, but how about
> debugging a non-portable feature like dynamic libraries?

But what do you think is a good way to print a function pointer when it
is, say, twice as wide as an object pointer? While, in general, object
pointers are as wide, or smaller than a void*, a function pointer can
be much wider.

Here's a function that returns a hexadecimal image of any object,
given its address and its size in bytes. The caller needs to free()
the result after using it.

#define NIBBLES_PER_BYT E ((CHAR_BIT+3)/4)

char *hex_image(void *addr, size_t len)
{
char *result = malloc(NIBBLES_ PER_BYTE * len + 1);
unsigned char *in = addr;
char *out = result;
size_t i;

if (result == NULL) return NULL;

for (i = 0; i < len; i ++) {
sprintf(out, "%0*x", NIBBLES_PER_BYT E, *in);
in ++;
out += NIBBLES_PER_BYT E;
}
return result;
}

It can be simplified a little if you don't mind assuming CHAR_BIT==8.

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