3 ms·

The literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.

• lonelappde 7y ago
  Why does the spec mandate support for useless bad code instead of banning it?
  • majewsky 7y ago
    1. Probably backwards-compatibility. 2. While you wouldn't write &*E by hand, it can easily arise from a macro expansion.
  • Ericson2314 7y ago
    `E` is an lvalue --- a location that only becomes a load/store when it is converted to an rvalue or assigned to. `&` takes an lvalue and gives a pointer to that location, so `E` is eliminated without being converted to an rvalue or assigned to, so no harm done. The real question if why have "lvalues" at all. If assignment always had to have a pointer on the left hand: &a := ..., b := ... rather than: a = ..., , *b = ... then this problem goes away.
• mehrdadn 7y ago
  Oh man, I wrote that as a shorthand for something like int& v = *p; foo(&v)... is there a difference in that case (C++ I guess)? I thought it was always illegal to dereference null pointers regardless of the specific token sequence or whether it's C or C++.
  • edflsafoiewq 7y ago
    Yeah, I thought that's what you meant. C++ doesn't special case &٭. C didn't before C99 either I think. It's not the exact token sequence actually; &(٭E) does the same thing.
    • saagarjha 7y ago
      I believe C++ does special-case that, as *foo when foo is an empty lvalue and it’s trying to assign that to an rvalue that is undefined.
• deleted 7y ago
  [deleted]