4 ms·
Is it possible they would be served by a different standard where C is a high-level assembly? Although admittedly, "&*p" to me reads as 'load p' and therefore u
by ludamad 7y ago
Is it possible they would be served by a different standard where C is a high-level assembly? Although admittedly, "&*p" to me reads as 'load p' and therefore undefined behaviour
- edflsafoiewq 7y agoThe literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.
- lonelappde 7y agoWhy does the spec mandate support for useless bad code instead of banning it?
- majewsky 7y ago1. 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 agoOh 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 agoYeah, 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 agoI 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]