https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #8) > I Know there has been discussion about &a->f not being a NULL pointer even > but I cannot find it right now. Finally found it: PR30368 comment #3: The C standard still says that is undefined. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf : 6.5.3.2/3: 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. ---- CUT ---- In the case of &a->f, it is the same as &((*a).f). There is no discussion in the above about the . operator .... NOTE also the commentry comments in the margin: Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points. Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime. ---- CUT ---- Again there is the no discussion about -> or . here. So Again &a->f cannot be null even if a is null.
