[cfe-dev] (Request for comments) Implicit cast kind for initialization of references.

[Enea Zaffanella]

Il 25/10/2011 09:51, David Blaikie ha scritto:
[...snip...]
>> The wording in C++0x 8.3.2 p5 says:
>>
>>  A reference shall be initialized to refer to a valid object
>>  or function. [Note: in particular, a null reference cannot
>>  exist in a well-defined program, because the only way to create
>>  such a reference would be to bind it to the “object” obtained
>>  by dereferencing a null pointer, which causes undefined behavior.
>>
>> Now, lvalue references are initialized using lvalues. If there could be
>> no invalid lvalues at all, then why stating the first sentence above?
> 
> Simple - dangling references. I'm not entirely sure that the spec says
> such things are immediate UB (though I suppose it should be... ).

If your point of view is consistently pursued (i.e., we can not
*compute* an invalid lvalue without incurring UB), then we will not be
able to compute the dangling reference at all; hence, the provision
above about proper initialization of references would again be pointless.

If we stick to the other point of view (i.e., some invalid lvalues can
be computed without incurring UB and the UB is incurred when *using*
them in certain ways) then the sentence will make more sense, imho.

>> It is also worth to stress the use of words "in particular" in the Note
>> above: as far as I understand, it suggests that the real cause of UB is
>> that we are *binding* the invalid lvalue to a reference (i.e., it is not
>> the mere action of computing the invalid lvalue).
> 
> I'd err the other way & assume the wording means that it's UB by
> dereferencing null, not the act of binding that to a reference.
> 
> Here's at least one piece of wording from the standard that states
> explicitly that the act of dereferencing something is immediate UB:
> 
> "The effect of dereferencing a pointer returned as a request for zero
> size is undefined."
>
> - 3.7.4.1 [basic.stc.dynamic.allocation] paragraph 2

This is quite different.
Note 35 says: "C++ differs from C in requiring a zero request to return
a non-null pointer." So, it looks like the pointer returned as a request
for zero size could be a "wild" pointer, i.e., much worse than the null
pointer or an off-by-one pointer. For instance, as far as I remember,
the simple act of *computing* an off-by-2 pointer can lead to UB, even
before any attempt to read it, store it or dereference it.

> Though I'm still trying to find the wording that supports the more
> general/obvious case of dereferencing null (or a dangling pointer,
> etc), I'd be fairly sure it's the same case.
> 
> - David

Also see the following change to the standard, which afaict has been
approved and entered the new C++11 standard:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1102

In few words, they explicitly removed the usage of null pointer
dereferencing as an example of UB *because* there are discussions going
on arguing that UB is not caused by dereferencing, but by later uses of
the invalid lvalue.

It would be really interesting if someone in contact with people in the
standardization committee could write here their point of view (e.g.,
reporting whether or not there have been progresses in those discussions).

Enea.