new CI builds
Berthold Stoeger
bstoeger at mail.tuwien.ac.at
Tue Apr 21 00:20:46 PDT 2020
Ok, this one is weird.
On Dienstag, 21. April 2020 08:44:09 CEST Chirana Gheorghita Eugeniu Theodor
wrote:
> /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
> _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
> _Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator<int>;
> std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
> _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
> this->size(), true)' failed.
That appears to be g++, right? To me this looks like it trips on an assertion
of a "vector[n]" access. The one thing I found in the offending function was a
construct of the type
"&mean[0]"
to pass an array down to C, which *technically* is indeed undefined behavior
if "mean" is empty. However, the whole point of operator[] is that it is
unchecked and as long as the callee doesn't access the array, this should work
just fine. After all it is only taking an address.
Therefore, I replaced above construct by "mean.data()" and put the call in an
if for good measure:
https://github.com/Subsurface-divelog/subsurface/pull/2778
Please test this.
If my suspicion is correct, I consider that very unfriendly behavior of the
compiler / library. @Dirk: does that version compile with other than the
default settings?
Berthold
More information about the subsurface
mailing list