https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392
Benjamin Priour <vultkayn at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vultkayn at gcc dot gnu.org
--- Comment #1 from Benjamin Priour <vultkayn at gcc dot gnu.org> ---
Access to end iterator should be flagged as undefined behavior.
Detecting invalidation is a difficult problem, as many methods are only
sometimes invalidating.
Checking a reallocation of the underlying container, e.g. for vectors, is
(always?) a good check, but it is not sufficient, e.g. consider
unordered_map.rehash(0)
Additionally, flagging all calls to "possibly invalidating operations" will
obviously lead to too
many false positive.
Thus, it might be relevant to have multiple attributes that keep track of
different kinds of invalidation.
Invalidating operations not only differ on their certainty, but on the
iterator(s) they invalidate.
Some will invalidate every iterators, while some
[[gnu::invalidate]] - always invalidate
[[gnu::invalidate(resize[, size_varname, capacity_varname, factor_varname ])]]
- All iterators are invalidated ? Examples of such case is a vector's size
exceeding its capacity, or a hashmap too loaded.
Would be detected by keeping track of push*, emplace*, insert* methods, as
well as clear, extract, erase.
If size_, capacity_ and factor_varname are provided, the invalidation is
done only if size/capacity >= factor.
[[gnu::invalidate(swap)]] - Both containers should be invalidated. Name
probably ill-chosen since swapping two lists invalidates nothing.
[[gnu::invalidate(rehash)]] - Generic remapping of every key -> element. This
one I think could be entirely replaced by the following.
[[gnu::invalidate(adaptor)]] - Look at the underlying container invalidation
rule.
[[gnu::invalidate(_from_[, _to_[, _step_]])]] - Invalidate all iterators from
_from_ to _to_ (default end()), with a jump of _step_ (default 1).
Or combine them.
For adaptors, we must look at their underlying containers.
What policy to take for unknown parameters ?
Typically if the load factor is determined at runtime, we simply cannot
precisely determine the event.
I believe that in such case, either the previous known value is used by the
analyzer as a heuristic, or if no other known user-provided value was given,
we use the implementation's default value.
When invalidating a range, how to determine the "following" iterators, that
should be invalidated, when we are not dealing with random iterators ?
Is there even such a case in the standard library, where a method over a
container without random iterators invalidates a range/ a subset of all
iterators ?
I didn't find any, and it is also counter-intuitive, and std::*_list certainly
are not.
More research needed.
