[RFC] list::remove vs const& arguments...

[Chris Jefferson]

Paolo Carlini wrote:

> Hi,
>
> we have got a PR, libstdc++/17012, reporting a memory error (both 
> valgrind
> and purify agree) for this pattern of usage:
>
>  list<int> var;
>  var.push_back(0);
>  ...
>  list<int>::iterator i0 = var.begin();
>  var.remove(*i0);
>
> skipping any irrelevant detail, the point is of course that the iteration
> in list::remove, having removed the first element, then refers to 
> deallocated
> memory. In turn, this is due to argument passing by const reference (*).
>
> Now, this is not a completely new issue for the libstdc++ list: we 
> already
> briefly touched upon it when discussing the optimization of std::fill: I
> clearly remember both Nathan and Martin posting comments.
>
I have not yet read this previous conversation (I intend to), but it 
seems to me that this is part of a general problem of mutating algorithm 
which accept parameters of type "const T&". When a function accepts two 
ranges the standard is careful to state how they can be related to each 
other. I am surprised the standard doesn't say things like "const T& 
parameter must not be reachable by derefencing any pointer in the range 
[first,last)" or even more simply "the value of const T& parameter must 
not change during the execution of this algorithm" (unless of course 
that kind of thing does want to be allowed). As I suspect has been 
discussed before, this problem also harms optimisation quite a bit, as 
g++ can't assume the const T& parameter is changed every time we 
dereference a pointer...

Chris