push to obs pls. On Tue, Apr 21, 2020, 10:20 Berthold Stoeger <[email protected]> wrote:
> 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 > > > >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
