获取未初始化指针的地址是未定义的行为吗？

Question

N1570 states that this is undefined behavior:

§J.2/1 The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).

And in this case, our pointer has an indeterminate value:

§6.7.9/10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, then:

— if it has pointer type, it is initialized to a null pointer;

I then presume the following test program exhibits undefined behavior:

#include <stdio.h>

int main(void) {
    char * ptr;
    printf("%p", (void*)&ptr);
}

My motivating concern is the strtol function. First, let me quote the parts of N1570 related to the endptr parameter:

§7.22.1.4/5 If the subject sequence has the expected form and the value of base is zero, the sequence of characters starting with the first digit is interpreted as an integer constant according to the rules of 6.4.4.1. [...] A pointer to the final string is stored in the object pointed to by endptr , provided that endptr is not a null pointer.

§7.22.1.4/7 If the subject sequence is empty or does not have the expected form, no conversion is performed; the value of nptr is stored in the object pointed to by endptr , provided that endptr is not a null pointer.

This implies that endptr needs to be pointing to an object, and also that endptr is at some point dereferenced. For example, this implementation does so :

if (endptr != 0)
    *endptr = (char *)(any ? s - 1 : nptr);

Yet, this highly upvoted answer as well as this man page both show endptr being passed to strtol uninitialized. Is there an exception which makes this not undefined behavior?

Answer 1

The pointer's value and its address are not the same.

void *foo;

That pointer has an undefined value, but the address of foo , ie the value of &foo , must be well-determined (since otherwise we can't access it).

At least that's my intuitive understanding, I didn't dig up the standard now, I just think you're mis-reading it.

When talking about code, the two are sometimes confused ("what's the address of that pointer?" can mean "what's the value of that pointer, what address is it pointing to?") but they are really distinct.

Answer 2

In this expression:

&ptr

the address of the & operand, ie, the address of the ptr object is yielded but the ptr object is never evaluated.

(C11, 6.3.2.1p2) "Except when it is the operand of the sizeof operator, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion."

Answer 3

No. It's not undefined behaviour. Only ptr is uninitialized and has indeterminate value but &ptr has a proper value.

What the standard quote on strtol says:

...If the subject sequence is empty or does not have the expected form, no conversion is performed; the value of nptr is stored in the object pointed to by endptr, provided that endptr is not a null pointer.

That above quote is talks about a call like this:

strtol(str, 0, 10);

The call in the man page and the linked answer are perfectly fine.

Answer 4

See this example

char * ptr; 

Since ptr is not pointing to any object, dereferencing it invokes undefined behavior. But when you pass its address to strtol , having syntax

long int strtol(const char *nptr, char **endptr, int base);  

in statement

long parsed = strtol("11110111", &ptr, 2);   

the endptr parameter of strtol is pointing to object ptr and derefeencing it will not invoke any UB.

Answer 5

I only have access to N1256 but I will be surprised if there is any material change.

The most relevant section is "6.5.3.2 Address and indirection operators"

And in particular paragraph 3 (my emphasis):

Semantics

3 The unary & operator yields the address of its operand. If the operand has type ''type'', the result has type ''pointer to type''. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

None of the cited paragraphs in the OP apply because as many have pointed out. The value of something and its address are very different.

I would argue that the absence of any restriction on & regarding uninitialized values taking their address is permitted (by the absence of prohibition).

NOTE: We all know it's fine but it's very rare to find statements in these standards that explicitly say "Yes you can do so & so."