Date: Mon, 28 Oct 2024 09:07:55 +0100
On 28/10/2024 08.24, Sebastian Wittmeier via Std-Proposals wrote:
> Hi Jens,
>
> as far as I understand the notion of "discarded value expression" made it unclear, whether (*nullptr) was UB.
Hm.
> According to https://eel.is/c++draft/expr.ref#2
>
> "For the first option (dot), if the /id-expression/ <https://eel.is/c++draft/expr.prim.id.general#nt:id-expression> names a static member or an enumerator, the first expression is a discarded-value expression ([expr.context] <https://eel.is/c++draft/expr.context>)"
>
> And according to https://eel.is/c++draft/expr.context#2
>
> "In some contexts, an expression only appears for its side effects. <https://eel.is/c++draft/expr.context#2.sentence-1> Such an expression is called a /discarded-value expression/ <https://eel.is/c++draft/expr.context#def:discarded-value_expression>. <https://eel.is/c++draft/expr.context#2.sentence-2>"
>
>
>
> So the result of (*nullptr) was irrelevant with the previous wording, only the side effects mattered. And side effects were mostly intended ones, which had to be fulfilled (e.g. a function being called), it was at least unclear, if just a non-overloaded dereferencing (which would lead to UB for nullptr, but has no effect on any valid target) is a side effect.
And
T *p = nullptr;
static_cast<T&>(*p).f();
would also be ok, despite the fact that empty lvalues don't exist?
However,
T& g(T& x) { return x; }
g(*p).f();
is obviously disallowed.
Where is the limit?
> The change made it clear that (*nullptr) always leads to UB.
>
> You are saying, it was clear beforehand?
I said it was always undefined. Implicitly undefined before, now explicit undefined
behavior. But since that implicitness didn't help clarity, we're now explicit.
Jens
> Best,
>
> Sebastian
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 28.10.2024 07:58
> *Betreff:* Re: [std-proposals] Calling methods on a nullptr
> *An:* std-proposals_at_[hidden];
> *CC:* Jens Maurer <jens.maurer_at_[hidden]>;
>
> > 2823 made it clear that (*nullptr) is always UB.
>
> What would the result of *nullptr be, with the previous wording?
>
> Jens
>
>
>
>
> Hi Jens,
>
> as far as I understand the notion of "discarded value expression" made it unclear, whether (*nullptr) was UB.
Hm.
> According to https://eel.is/c++draft/expr.ref#2
>
> "For the first option (dot), if the /id-expression/ <https://eel.is/c++draft/expr.prim.id.general#nt:id-expression> names a static member or an enumerator, the first expression is a discarded-value expression ([expr.context] <https://eel.is/c++draft/expr.context>)"
>
> And according to https://eel.is/c++draft/expr.context#2
>
> "In some contexts, an expression only appears for its side effects. <https://eel.is/c++draft/expr.context#2.sentence-1> Such an expression is called a /discarded-value expression/ <https://eel.is/c++draft/expr.context#def:discarded-value_expression>. <https://eel.is/c++draft/expr.context#2.sentence-2>"
>
>
>
> So the result of (*nullptr) was irrelevant with the previous wording, only the side effects mattered. And side effects were mostly intended ones, which had to be fulfilled (e.g. a function being called), it was at least unclear, if just a non-overloaded dereferencing (which would lead to UB for nullptr, but has no effect on any valid target) is a side effect.
And
T *p = nullptr;
static_cast<T&>(*p).f();
would also be ok, despite the fact that empty lvalues don't exist?
However,
T& g(T& x) { return x; }
g(*p).f();
is obviously disallowed.
Where is the limit?
> The change made it clear that (*nullptr) always leads to UB.
>
> You are saying, it was clear beforehand?
I said it was always undefined. Implicitly undefined before, now explicit undefined
behavior. But since that implicitness didn't help clarity, we're now explicit.
Jens
> Best,
>
> Sebastian
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 28.10.2024 07:58
> *Betreff:* Re: [std-proposals] Calling methods on a nullptr
> *An:* std-proposals_at_[hidden];
> *CC:* Jens Maurer <jens.maurer_at_[hidden]>;
>
> > 2823 made it clear that (*nullptr) is always UB.
>
> What would the result of *nullptr be, with the previous wording?
>
> Jens
>
>
>
>
Received on 2024-10-28 08:07:58