Tom Hughes writes:
But I think upstream is giving very bad advice...
That define does not "add extra crashes" in the way that they
seem to think - well I mean it does literally but those crashes
are reports of program errors on their part.
Specifically in this case they appear to be accessing a
std::vector at an index beyond the end, so they are accessing
memory that may not be allocated at all, and if it is does
not belong to the vector in question. So the program is quite
likely to crash there one day anyway, the extra assertion just
makes sure it always does.
I believe that the following construct trips this assertion:
# std::vector<int> foo;
#
# std::vector<int> bar;
#
# // Populate foo with something.
#
# std::copy(&foo[0], &foo[foo.size()], std::back_insert_iterator{bar});
There's nothing wrong with this. There is no out of bounds access. I do not
believe that this is undefined behavior. The defined semantics of
std::vector, and its operator[], are well defined here.
I ran into these new assertions with my own code as well, after updating to
F28 (where they were enabled by default the first time, IIRC, not sure why
this shows up only now, for that package).
I ended up tweaking my code to avoid the assertions, rather than disabling
them. For this particular situation, my original change was to try
std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar});
But that still tripped the assertion when the foo vector was empty, so I had
wrap this inside an if().
This was a somewhat silly excersize. But, I do agree that these assertions
are better to have, than have not.