25

I was playing around with gcc and tried the following bit of code:

int A = 42;
int *B = &A;
int *C = &*B;

And C == &A, as expected. But when I try:

int *B = NULL;
int *C = &*B;

Turns out C == NULL, and no segfault. So &*B is not actually dereferencing B before taking its address.

My guess is that the preprocessor is stripping out instances of &* and *& before they even get to the compiler since they negate each other, but I can't find any documentation to verify whether this is standard C or compiler-specific.

Is the preprocessor stripping out &* and *&, and can I expect this behavior from any given compiler?

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
evenex_code
  • 843
  • 1
  • 8
  • 20
  • 4
    The compiler might optimize this statement, but I doubt that the preprocessor would. – ApproachingDarknessFish Jan 21 '14 at 01:22
  • 9
    It is not "stripped" by the pre-processor. It's the compiler itself that's recognizing that `&*` is a no-op. – Hot Licks Jan 21 '14 at 01:25
  • This is undefined behavior. The optimizer happened to process your code in such a way that nothing catastrophic happened, but the computer is free to segfault, glitch out later, or make demons fly out your nose. – user2357112 Jan 21 '14 at 07:27
  • 10
    The preprocessor better not remove it: `int *p, *q; int foo = *p & *q;` - perfectly legal code but only the compiler can detect it's the binary operator. – MSalters Jan 21 '14 at 08:33
  • There has been said a lot about `&*` now. But you are as well asking for `*&`, which is trivial, because not dangerous: if `&` is allowed, it is safe to dereference it again, making `*&` a noop as well. But as nothing can happen during this process, it doesn't require special treatment. – glglgl Jan 21 '14 at 09:28

2 Answers2

31

This is not being stripped out by the the pre-procesor, &* just ends up being equivalent to the pointer itself, we can see this by going to draft C99 standard 6.5.3.2 Address and indirection operators paragraph 4 which says:

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

and footnote 87 says:

Thus, &*E is equivalent to E (even if E is a null pointer),[...]

and paragraph 3 says (emphasis mine):

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.

Update

It is probably worth it to note that for gcc and clang you can view the results of pre-processing by using the -E flag(see it live) and in Visual Studio /EP(see it live).

Also, worth noting that as MSalters said in his comment just having the two tokens &* is not sufficient to understand the context, as his example shows:

int *p, *q ;
int foo = *p & *q ;

So just removing &* would not even be possible during the pre-processing stage since you would not have sufficient information available to determine whether & was the address of operator or bitwise and operator.

Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • 5
    I think this answers my question. The answer is no, it is not stripped out: the compiler itself considers it equivalent to the pointer. Since its in the standard, we can expect the behavior to be consistent across compilers. – evenex_code Jan 21 '14 at 01:24
  • @evenex_code it should be consistent across compilers and if not it would have to be documented. – Shafik Yaghmour Jan 21 '14 at 01:25
  • @Shafik Any idea whether this applies to the C++11 standard as well. It'd answer [this](https://stackoverflow.com/questions/21178903/reinterpret-cast-behavior-when-dereferencing-a-void-pointer), as yet unanswered, question I posted. Post an answer quoting this and show that it also applies to C++11, and you'll have +25 rep :) – Praetorian Jan 21 '14 at 01:26
  • 2
    Keep in mind that the compiler does not know, when it evaluates `*B`, whether it's an *l-value* or an *r-value*, so it assumes *l-value* until proven otherwise and returns value of B (without dereferencing). And the `&` operator applied to an *l-value* will simply return the address represented by the *l-value* (as an *r-value*). – Hot Licks Jan 21 '14 at 01:29
  • @Praetorian as far as I know it does not apply to *C++11*, I will dig into it when I have a chance. – Shafik Yaghmour Jan 21 '14 at 03:07
  • @HotLicks maybe I am misunderstanding your comment but paragraph 3 says `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` which means it is unevaluated. Which does not seem to match your comment. – Shafik Yaghmour Jan 21 '14 at 04:22
  • @ShafikYaghmour - The point is that the compiler cannot evaluate `*` (ie, perform the memory fetch) until it knows if it's an l-value or an r-value. It doesn't know that until it sees the `&` (which requires an l-value) so it doesn't get evaluated. And the `&` is not evaluated because it never actually "evaluates" anything, but rather changes an l-value to an r-value without causing the fetch. – Hot Licks Jan 21 '14 at 12:24
10

The preprocessor does not elide &*. However, the C 2011 standard says in 6.5.3.2 3, about &:

If the operand [of &] 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.

As required by the constraints mentioned above, the operand of * must have pointer type. Thus, &*3 is not changed to 3 by this clause; it violates the constraints because 3 does not have pointer type. Additionally, &*x is not quite changed to x, since the result is not an lvalue. For example, this is not allowed:

int a, *x;
x   = &a; // Normal, allowed.
&*x = &a; // Not allowed; `&*x` does not became exactly the same as `x`.
Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312