取消引用指向数组的 NULL 指针在 C 中是否有效？

Question

Is this behavior defined or not?

volatile long (*volatile ptr)[1] = (void*)NULL;
volatile long v = (long) *ptr;

printf("%ld\n", v);

It works because by dereferencing pointer to array we are receiving an array itself, then that array decaying to pointer to it's first element.

Updated demo: https://ideone.com/DqFF6T

Also, GCC even considers next code as a constant expression:

volatile long (*ptr2)[1] = (void*)NULL;
enum { this_is_constant_in_gcc = ((void*)ptr2 == (void*)*ptr2) };
printf("%d\n", this_is_constant_in_gcc);

Basically, dereferencing ptr2 at compile time;

Answer 1

This:

long (*ptr)[1] = NULL;

Is declaring a pointer to an "array of 1 long " (more precisely, the type is long int (*)[1] ), with the initial value of NULL . Everything fine, any pointer can be NULL .

Then, this:

long v = (long) *ptr;

Is dereferencing the NULL pointer, which is undefined behavior . All bets are off, if your program does not crash, the following statement could print any value or do anything else really.

Let me make this clear one more time: undefined behavior means that anything can happen . There is no explanation as to why anything strange happens after invoking undefined behavior, nor there needs to be. The compiler could very well emit 16-bit Real Mode x86 assembly, produce a binary that deletes your entire home folder, emit the Apollo 11 Guidance Computer assembly code, or whatever else. It is not a bug. It's perfectly conforming to the standard.

---

The only reason your code seems to work is because GCC decides, purely out of coincidence , to do the following ( Godbolt link ):

mov     QWORD PTR [rbp-8], 0    ; put NULL on the stack
mov     rax, QWORD PTR [rbp-8]
mov     QWORD PTR [rbp-16], rax ; move NULL to the variable v

Causing the NULL -dereference to never actually happen. This is most probably a consequence of the undefined behavior in dereferencing ptr ¯\\_(ツ)_/¯

---

Funnily enough, I previously said in a comment:

dereferencing NULL is invalid and will basically always cause a segmentation fault.

But of course, since it is undefined behavior that "basically always" is wrong. I think this is the first time I ever see a null-pointer dereference not cause a SIGSEGV.

Answer 2

Is this behavior defined or not?

Not.

 long (*ptr)[1] = NULL; long v = (long) *ptr; printf("%ld\\n", v);

It works because by dereferencing pointer to array we are receiving an array itself, then that array decaying to pointer to it's first element.

No, you are confusing type with value. It is true that the expression *ptr on the second line has type long[1] , but evaluating that expression produces undefined behavior regardless of the data type, and regardless of the automatic conversion that would be applied to the result if it were defined.

The relevant section of the spec is paragraph 6.5.2.3/4 :

The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type ''pointer to type'', the result has type ''type''. If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.

A footnote goes on to clarify that

[...] Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer [...]

It may "work" for you in an empirical sense, but from a language perspective, any output at all or none is a conforming result.

Update:

It may be interesting to note that the answer would be different for explicitly taking the address of *ptr than it is for supposing that array decay will overcome the undefinedness of the dereference. The standard provides that, as a special case, where the operand of the unary & operator is the result of a unary * operator, neither of those operators is evaluated. Provided that all relevant constraints are satisfied, the result is as if they were both omitted altogether, except that it is never an lvalue.

Thus, this is ok:

long (*ptr)[1] = NULL;
long v = (long) &*ptr;

printf("%ld\n", v);

On many implementations it will reliably print 0, but do note that C does not specify that it must be 0.

The key distinction here is that in this case, the * operation is not evaluated (per spec). The * operation in the original code is is evaluated, notwithstanding the fact that if the pointer value were valid, the resulting array would be converted right back to a pointer (of a different type, but to the same location). That does suggest an obvious shortcut that implementations may take with the original code, and they may take it, if they wish, without regard to whether ptr 's value is valid because if it is in valid then they can do whatever they want.

Answer 3

To just answer you´re provided questions:

1. Is dereferencing a NULL pointer to array valid in C?

No.

2. Is this behavior defined or not?

It is classified as "undefined behavior", so it is not defined.

---

Never mind of the case, that this trick with the array, maybe will work on some implementations and it fills absolutely no needs to do so (I imply you are asking out of curiousity), it is not valid per the C standard to dereference a NULL pointer in any way and will cause "Undefined Behavior".

---

Anything can happen when you implement such statements into your program.

Look at the answers on this question, which explain why:

What EXACTLY is meant by "de-referencing a NULL pointer"?

One qoute from Adam Rosenfield´s answer :

A null pointer is a pointer that does not point to any valid data (but it is not the only such pointer). The C standard says that it is undefined behavior to dereference a null pointer. This means that absolutely anything could happen: the program could crash, it could continue working silently, or it could erase your hard drive (although that's rather unlikely).

Answer 4

Is this behavior defined or not?

The behavior is undefined because you are applying * operator to a pointer that compares equal to null pointer constant.

The following stackoverflow thread tries to explain what undefined behavior is: Undefined, unspecified and implementation-defined behavior