[conv.lval] Fix cross-reference for 'invalid pointer value' #5886
Conversation
|
With a |
Thanks. |
Could you please point out where that definition is exactly? |
|
It's https://eel.is/c++draft/basic.compound#3.4 by exhaustion. |
|
For instance, https://eel.is/c++draft/basic.stc.general#4 refers to the correct place. Perhaps it'd be better to use a |
|
Right, so isn't |
|
A label would be nice, too. |
I'm not sure. But at the very least, just like how https://eel.is/c++draft/basic.compound#3.2 refers to where it's specified how to form a pointer past the end of an object, p3.4 could refer to [basic.stc.general]. |
|
Yes, could you make that change then? |
|
As a separate PR? I'm not the author of this one. |
|
Sorry, no, I should have directed that to the PR author! @blackteahamburger ^^^ |
Done. |
| @@ -666,7 +666,7 @@ | |||
| the glvalue. | |||
|
|
|||
| \item Otherwise, if the object to which the glvalue refers contains an invalid | |||
| pointer value\iref{basic.stc.dynamic.deallocation}, the behavior is | |||
| pointer value\iref{basic.compound}, the behavior is | |||
There was a problem hiding this comment.
What about here, shouldn't this also refer to basic.stc.general for the definition of "invalid pointer"? Why is basic.compound a good reference?
There was a problem hiding this comment.
What about here, shouldn't this also refer to basic.stc.general for the definition of "invalid pointer"? Why is basic.compound a good reference?
But [basic.stc.general]/4 specifies how to form an invalid pointer value, while [basic.compound]/3.4 is the definition (so [basic.stc.general]/4 refers to [basic.compound]/3.4).
And I think
Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior. Any other use of an invalid pointer value has implementation-defined behavior.
in [basic.stc.general]/4 should be better placed in [basic.compound]/3. But [basic.compound]/3 may need to be split because it is too long.
There was a problem hiding this comment.
Sorry, could you explain a bit how basic.general is the definition? I don't see "invalid" mentioned in basic.general except for in that list in p3 (which doesn't seem like a definition?) and in notes.
There was a problem hiding this comment.
[basic.compound] p3 contains the taxonomy of pointer values. It states "there exists a pointer value that is an invalid pointer value".
[basic.stc.general] p4 tells us about one way how to obtain an invalid pointer value (maybe there are others). It also explains a bit of the semantics of an invalid pointer value, but this should probably be moved elsewhere in the long run. For example, [conv.lval] p3.3 tells us a little more about an invalid pointer value.
There was a problem hiding this comment.
Yes, right. In fact, [conv.lval] is the very subject of this PR. I'm not sure where the definition of invald value could be moved to improve the presentation; isn't basic.stc.general a good place? We could just add a cross reference to it from [basic.compound]/(3.4).
There was a problem hiding this comment.
Sure, but that's converted to use "operator*" (expr.ref p2 and expr.mptr.oper p3).
There was a problem hiding this comment.
Maybe the last two sentences of [basic.stc.general]p4 should become a note?
Except that we seem to lack normative statements elsewhere.
There was a problem hiding this comment.
Yes, the normative wording would have to move somewhere more appropriate.
There was a problem hiding this comment.
CWG2822 moves the normative wording "somewhere else", for unrelated reasons.
There was a problem hiding this comment.
Shall we wait for that to land then?
tkoeppe
added
the
decision-required
|
I think we can derive some useful cleanup opportunities here, so let's keep this open and look at it again some time. |
The definition of 'invalid pointer value' is in [basic.compound] rather than [basic.stc.dynamic.deallocation].