On Tue, 18 Jan 2022, Martin Sebor wrote: > On 1/18/22 01:36, Richard Biener wrote: > > On Mon, 17 Jan 2022, Martin Sebor wrote: > > > >> On 1/17/22 07:32, Richard Biener via Gcc-patches wrote: > >>> The warning control falls into the C++ trap of using a reference > >>> to old hashtable contents for a put operation which can end up > >>> re-allocating that before reading from the old freed referenced to > >>> source. Fixed by introducing a temporary. > >> > >> I think a better place to fix this and avoid the gotcha once and > >> for all is in the GCC hash_map: C++ containers are expected to > >> handle the insertion of own elements gracefully. > > > > I don't think that's reasonably possible if you consider > > > > T *a = map.get (X); > > T *b = map.get (Y); > > map.put (Z, *a); > > map.put (W, *b); > > This case is up to the caller to handle, the same as anything else > involving pointers or references into reallocated storage (it's no > different in C than it is in C++). > > The specific case I'm referring to is passing a pointer or reference > to a single element in a container to the first modifying call on > the container.
Huh, that's a quite special case I'm not sure "fixing" will avoid the mistake. > > > > the only way to "fix" it would be to change the API to not > > return by reference for get, remove get_or_insert (or change > > its API to also require passing the new value). > > No, the fix is to have the modifying function create a copy of > the element being inserted before reallocating the container. Sure, that's possible I guess. Richard.
