PR 57779 New debug check

[François Dumont]

On 07/11/2013 11:13 PM, Jonathan Wakely wrote:
> On 11 July 2013 21:49, Jonathan Wakely wrote:
>> On 11 July 2013 21:16, François Dumont wrote:
>>>      I am indeed dereferencing the end iterator but as long as it is just to
>>> get the address of the resulting element it is fine.
>> I don't think that's what the standard says.
>>
>> C99 and later say that &*p is OK if p is a null pointer, but C++ does
>> not have the same rule, see e.g.
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 for an
>> open issue on this topic.  Even if that proposed resolution were to be
>> accepted (very unlikely, it's sat untouched for many years) what
>> you're doing is not the same, because you dereference an iterator
>> which returns a reference, and _then_ you take the address, so it's
>> equivalent to:
>>
>> T& end() { T* p = 0; return *p; }
>> T* p = &end();
>>
>> That forms an invalid reference before taking the address, so is not
>> the same as &*(T*)0, it's more like &(T&)*(T*)0 and I'm uncomfortable
>> with that.
> ... but willing to be convinced if I'm wrong :-)
>
Even if I still don't see what can goes wrong here I agree that in 
theory this is bad so here is another proposal that do not have this 
drawback. I also consider all your remarks I think except the Paolo 
remark about using std::greater. If I am playing with plain pointers why 
would I need to use std::less or std::greater ?

I also introduced a small helper to assert only when GNU extension is 
not making the call valid.

For set/map/unordered_set/unordered_map the call is fine because 
elements are not going to be inserted again so it is a no-op but I 
prefer to keep the debug assertion in this case because this is quite a 
useless operation that users better avoid.

François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 57779.patch
Type: text/x-patch
Size: 18173 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20130715/b6f2d55f/attachment.bin>