printf("%p\n", (void *)0);

[infobahn]

printf("%p\n", (void *)0); /* UB, or not? Please explain your answer. */

[Keith Thompson]

Quentarez <qu*******@cogn itiveprocess.co m> writes:

On Sat, 5 Mar 2005 22:20:00 +0000 (UTC), infobahn wrote:

printf("%p\n", (void *)0); /* UB, or not? Please explain your answer. */
I, personally, would not consider this to be UB.

I don't have supreme knowledge of the standard, nor do I have any
references to the standard to support this claim.

I decided to take a different route, and see what the compiler does with a
NULL pointer. I tested it on two compilers: MSVC6 and gcc 3.3.5.

Observing the behavior of any number of implementations doesn't
demonstrate that the behavior is defined. Undefined behavior is
exactly that, undefined. Specifically, it's

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

(C99 3.4.3p1)

Even assuming that it's UB, the behaviors of MSVC6 and gcc are
entirely consistent with the standard. (*Any* behavior would be
entirely consistent with the standard.)

The only way to determine whether a given construct invokes undefined
behavior is by a careful reading of the standard.
It has already been shown previous to this post that (void *)0 is indeed a
way to get a NULL pointer, so I will refer to it as a NULL pointer from now
on.
It's better to refer to this as a "null pointer", not a "NULL
pointer". NULL is a macro that expands to a null pointer constant;
using all-caps NULL for anything else is misleading.
From what I've learned, a pointer always points /somewhere/, even if that
somewhere is not where you intended.
Not necessarily. As far as the language is concerned a null pointer
points nowhere. (It might happen to point to some location in
physical or virtual memory, but no program can determine that without
invoking undefined behavior.)

More concretely, on a system with 128 megabytes of virtual memory, a
pointer with the value 0x10000000 (that's 256 megabytes) doesn't point
anywhere -- or maybe it points to a memory card you haven't installed
yet. (For the sake of this example, I'm making several assumptions
about pointers that are commonly true, but are not required by the
standard.)
From simply compiling and running the given code, I get the output 00000000
on MSVC6 and (nil) on gcc.
Using gcc on three different platforms, I get "0x0", "0", and "(nil)".
It's the runtime library, not the compiler, that implements printf.
(As far as the standard is concerned, the compiler and the library are
both part of the implementation; in other words, "gcc" is not a
complete description of the implementation. )

[snip]
Based on my observations, it seems that

printf("%p\n", (void *)0);

is not UB.

Based on your observations, it could very well be UB.

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

[Keith Thompson]

CBFalconer <cb********@yah oo.com> writes:

Andrey Tarasevich wrote:

... snip ...

This has already been covered above. Once again, the standard says
that null pointer arguments can be specifically allowed by the
specification of the concrete function from the standard library.
'free' function is a good example of such function: its
specification explicitly states that passing a null pointer to it
is OK (does noting). The specification of 'printf' does not say
that passing null pointers to it is OK. That's exactly what
constitutes the problem.

However the standard does say that dereferencing NULL is bad, and
that is exactly what is required for all usages of NULL in printf
except the %p descriptor. It is that omission that is giving some
people qualms.

For that matter, a printf implementation *could* attempt to
dereference the pointer associated with the "%p" descriptor (after an
appropriate conversion, of course). It might be useful for the "%p"
output to show both the value of the pointer and, say, the first few
bytes of the memory it points to. "The value of the pointer is
converted to a sequence of printing characters, in an
implementation-defined manner."

In my opinion such an implementation that blew up attempting to
dereference a null pointer would be less than useful, and would
violate what I presume to be the intent of the standard, but the
actual wording of the standard doesn't quite forbid it.

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

[Quentarez]

On Sun, 06 Mar 2005 20:48:01 GMT, Keith Thompson wrote:

Quentarez <qu*******@cogn itiveprocess.co m> writes:

On Sat, 5 Mar 2005 22:20:00 +0000 (UTC), infobahn wrote:

printf("%p\n", (void *)0); /* UB, or not? Please explain your answer. */

I, personally, would not consider this to be UB.

I don't have supreme knowledge of the standard, nor do I have any
references to the standard to support this claim.

I decided to take a different route, and see what the compiler does with a
NULL pointer. I tested it on two compilers: MSVC6 and gcc 3.3.5.

Observing the behavior of any number of implementations doesn't
demonstrate that the behavior is defined. Undefined behavior is
exactly that, undefined. Specifically, it's

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

(C99 3.4.3p1)

Even assuming that it's UB, the behaviors of MSVC6 and gcc are
entirely consistent with the standard. (*Any* behavior would be
entirely consistent with the standard.)

The only way to determine whether a given construct invokes undefined
behavior is by a careful reading of the standard.

It has already been shown previous to this post that (void *)0 is indeed a
way to get a NULL pointer, so I will refer to it as a NULL pointer from now
on.

It's better to refer to this as a "null pointer", not a "NULL
pointer". NULL is a macro that expands to a null pointer constant;
using all-caps NULL for anything else is misleading.

From what I've learned, a pointer always points /somewhere/, even if that
somewhere is not where you intended.

Not necessarily. As far as the language is concerned a null pointer
points nowhere. (It might happen to point to some location in
physical or virtual memory, but no program can determine that without
invoking undefined behavior.)

More concretely, on a system with 128 megabytes of virtual memory, a
pointer with the value 0x10000000 (that's 256 megabytes) doesn't point
anywhere -- or maybe it points to a memory card you haven't installed
yet. (For the sake of this example, I'm making several assumptions
about pointers that are commonly true, but are not required by the
standard.)

From simply compiling and running the given code, I get the output 00000000
on MSVC6 and (nil) on gcc.

Using gcc on three different platforms, I get "0x0", "0", and "(nil)".
It's the runtime library, not the compiler, that implements printf.
(As far as the standard is concerned, the compiler and the library are
both part of the implementation; in other words, "gcc" is not a
complete description of the implementation. )

[snip]

Based on my observations, it seems that

printf("%p\n", (void *)0);

is not UB.

Based on your observations, it could very well be UB.

Ah! My definition of UB was completely incorrect. Thank you very much for
your response and clarification! :)

[aegis]

Keith Thompson wrote:

Quentarez <qu*******@cogn itiveprocess.co m> writes:

On Sat, 5 Mar 2005 22:20:00 +0000 (UTC), infobahn wrote:

printf("%p\n", (void *)0); /* UB, or not? Please explain your

answer. */
I, personally, would not consider this to be UB.

I don't have supreme knowledge of the standard, nor do I have any
references to the standard to support this claim.

I decided to take a different route, and see what the compiler does with a NULL pointer. I tested it on two compilers: MSVC6 and gcc 3.3.5.
Observing the behavior of any number of implementations doesn't
demonstrate that the behavior is defined. Undefined behavior is
exactly that, undefined. Specifically, it's

behavior, upon use of a nonportable or erroneous program

construct or of erroneous data, for which this International Standard
imposes no requirements

(C99 3.4.3p1)

Even assuming that it's UB, the behaviors of MSVC6 and gcc are
entirely consistent with the standard. (*Any* behavior would be
entirely consistent with the standard.)

The only way to determine whether a given construct invokes undefined
behavior is by a careful reading of the standard.

It has already been shown previous to this post that (void *)0 is indeed a way to get a NULL pointer, so I will refer to it as a NULL pointer from now on.

It's better to refer to this as a "null pointer", not a "NULL
pointer". NULL is a macro that expands to a null pointer constant;
using all-caps NULL for anything else is misleading.

From what I've learned, a pointer always points /somewhere/, even if that somewhere is not where you intended.

Not necessarily. As far as the language is concerned a null pointer
points nowhere. (It might happen to point to some location in
physical or virtual memory, but no program can determine that without
invoking undefined behavior.)

It does point somewhere. It points to no object. And 'no object' does
not
mean 'nowhere'.

--
aegis

[Niklas Matthies]

On 2005-03-06 20:56, Keith Thompson wrote:
:

For that matter, a printf implementation *could* attempt to
dereference the pointer associated with the "%p" descriptor (after an
appropriate conversion, of course). It might be useful for the "%p"
output to show both the value of the pointer and, say, the first few
bytes of the memory it points to. "The value of the pointer is
converted to a sequence of printing characters, in an
implementation-defined manner."

The first few bytes of memory it points to is not part of the value
of the pointer, though (well, unless it points to itself...).
Arguably, converting "the value of the pointer" should never require
dereferencing the value.

-- Niklas Matthies

[Keith Thompson]

Niklas Matthies <us***********@ nmhq.net> writes:

On 2005-03-06 20:56, Keith Thompson wrote:
:

For that matter, a printf implementation *could* attempt to
dereference the pointer associated with the "%p" descriptor (after an
appropriate conversion, of course). It might be useful for the "%p"
output to show both the value of the pointer and, say, the first few
bytes of the memory it points to. "The value of the pointer is
converted to a sequence of printing characters, in an
implementation-defined manner."

The first few bytes of memory it points to is not part of the value
of the pointer, though (well, unless it points to itself...).
Arguably, converting "the value of the pointer" should never require
dereferencing the value.

That's a good point. My thought is that the phrase "in an
implementation-defined manner" might leave enough leeway to look at
what it points to (and it could actually be useful). But since it's a
void*, it's hard to decide how many bytes to display.

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

[Peter Nilsson]

Keith Thompson wrote:

Niklas Matthies <us***********@ nmhq.net> writes:

On 2005-03-06 20:56, Keith Thompson wrote:

For that matter, a printf implementation *could* attempt to
dereference the pointer associated with the "%p" descriptor
(after an appropriate conversion, of course).
And printing an integer could cause that integer to be converted
to a pointer and subsequently dereferenced. The standard doesn't
seem to preclude it, so it must be an option, right? ;)
It might be useful for the "%p" output to show both the value
of the pointer and, say, the first few bytes of the memory it
points to.
Your use of the word 'both' implies you already recognise the
distinction.
"The value of the pointer is converted to a sequence of
printing characters, in an implementation-defined manner."

The first few bytes of memory it points to is not part of the
value of the pointer, though (well, unless it points to
itself...). Arguably, converting "the value of the pointer"
should never require dereferencing the value.

That's a good point. My thought is that the phrase "in an
implementation-defined manner" might leave enough leeway to
look at what it points to...

Think about these...

char a[42];
printf("%p\n", a + 42);

char *p = malloc(0);
printf("%p\n", p);

More pragmatically, consider a conforming implementation
that allows pointers to be generated for all sorts of things,
including memory mapped I/O. Such an implementation would have
to check the pointer _very carefully_ to determine that
subsequent dereferencing will not reformat the harddisk!

--
Peter

[Keith Thompson]

"aegis" <ae***@mad.scie ntist.com> writes:

Keith Thompson wrote:

Quentarez <qu*******@cogn itiveprocess.co m> writes: [...]

> From what I've learned, a pointer always points /somewhere/, even
> if that somewhere is not where you intended.

Not necessarily. As far as the language is concerned a null pointer
points nowhere. (It might happen to point to some location in
physical or virtual memory, but no program can determine that without
invoking undefined behavior.)

It does point somewhere. It points to no object. And 'no object'
does not mean 'nowhere'.

Yes, it does. There isn't some mythical object called "no object".
"It points to no object" means the same as "It doesn't point to an
object".

To use a physical analogy, suppose I have a laser pointer that I can
use to point to various objects. If I aim it at an empty spot in the
sky, it's still pointing, but it's not pointing to any object. If I
turn it off, it's not pointing.

A null pointer is like a laser pointer that's turned off.

If you view it as a raw machine-level address (physical or virtual,
whichever is used for C pointers), a null pointer *might* happen to be
the address of some actual chunk of memory, or it might contain a
virtual address that's not mapped into the current process's address
space or a physical address that doesn't correspond to any real
memory. The C standard doesn't distinguish between these cases; as
far as C is concerned, a null pointer doesn't point. No program can
determine whether a null pointer acts as if it pointed to something
without invoking undefined behavior.

What the C standard says is that it "is guaranteed to compare unequal
to a pointer to any object or function"; it also says that applying
the unary "*" operator to an invalid pointer (including a null
pointer) invokes undefined behavior.

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

[Ben Pfaff]

Keith Thompson <ks***@mib.or g> writes:

For that matter, a printf implementation *could* attempt to
dereference the pointer associated with the "%p" descriptor (after an
appropriate conversion, of course). It might be useful for the "%p"
output to show both the value of the pointer and, say, the first few
bytes of the memory it points to.

That would make the following impossible to implement portably
without invoking undefined behavior, whereas I don't think it
should be:
printf("%p\n", malloc(0));
A real implementation would probably have extra knowledge though.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[aegis]

Keith Thompson wrote:

"aegis" <ae***@mad.scie ntist.com> writes:

Keith Thompson wrote:

Quentarez <qu*******@cogn itiveprocess.co m> writes: [...] > From what I've learned, a pointer always points /somewhere/, even > if that somewhere is not where you intended.

Not necessarily. As far as the language is concerned a null pointer points nowhere. (It might happen to point to some location in
physical or virtual memory, but no program can determine that without invoking undefined behavior.)

It does point somewhere. It points to no object. And 'no object'
does not mean 'nowhere'.

Yes, it does. There isn't some mythical object called "no object".
"It points to no object" means the same as "It doesn't point to an
object".

Noone said it is mythical. The standard clearly states that
the purpose of a null pointer is to distinguish between
pointing to an object and no object. You can think of it as having
a set of objects with one object for representing no object.
Let's call the special object the sentinel.
When our pointer points to the sentinel, it means 'no object'.
When our pointer is not pointing to the sentinel, it is pointing
to an object(except where the value is invalid). In either case,
our pointer points to something but is never 'turned off' since
it is always functioning. That is the point of pointers, you see?
To point to things. If the pointer were to be 'turned off' it would
stop functioning, in which case we would be unable to determine
if it points to the object that represents no object. ;-)

--
aegis