vector lightweight debug mode

[François Dumont]

Hi

    I completed vector assertion mode. Here is the result of the new
test you will find in the attached patch.

With debug mode:
/home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:375:
Error: attempt to advance a dereferenceable (start-of-sequence) iterator 2
steps, which falls outside its valid range.

Objects involved in the operation:
    iterator @ 0x0x7fff1c346760 {
      type =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<int*,
std::__cxx1998::vector<int, std::allocator<int> > >,
std::__debug::vector<int, std::allocator<int> > > (mutable iterator);
      state = dereferenceable (start-of-sequence);
      references sequence with type 'std::__debug::vector<int,
std::allocator<int> >' @ 0x0x7fff1c3469a0
    }
XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test


With assertion mode:
/home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1124:
Error: invalid insert position outside container [begin, end) range.

Objects involved in the operation:
    sequence "this" @ 0x0x7fff60b1f870 {
      type = std::vector<int, std::allocator<int> >;
    }
    iterator "__position" @ 0x0x7fff60b1f860 {
      type = __gnu_cxx::__normal_iterator<int const*, std::vector<int,
std::allocator<int> > >;
    }
XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test


As expected assertion mode doesn't detect invalid operation on the
iterator but only its usage later.

There is still one debug assertion I would like to use in assertion
mode: __valid_range. I could use it to check erase range and iterator
range used on the insert method. But for that it means including
<debug/helper_functions.h> and so:

#include <bits/stl_iterator_base_types.h>    // for iterator_traits,
                        // categories and _Iter_base
#include <bits/cpp_type_traits.h>        // for __is_integer

#include <bits/stl_pair.h>            // for pair

That looks fine to me, what do you think ?

François

On 19/09/2015 11:47, Jonathan Wakely wrote:
> On 19 September 2015 at 10:12, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 19 September 2015 at 08:31, François Dumont wrote:
>>> On 16/09/2015 22:29, Jonathan Wakely wrote:
>>>> No, because it is undefined to compare iterators that belong to
>>>> different containers, or to compare pointers that point to different
>>>> arrays.
>>>>
>>> (Written before Christopher reply:)
>>>
>>> At least program will compile only if iterator is coming from a vector
>>> of the same type. So behavior is undefined only if user pass an invalid
>>> iterator which is exactly what this check tries to detect, isn't it
>>> paradoxical ? If this undefined behavior results in the program abortion
>>> this is what should happen anyway. If it doesn't abort then the program
>>> will definitely not behaves as expected so this check doesn't make
>>> anything worst, no ?
>> The problem is that undefined behaviour can "travel backwards in time".
>>
>> It's not as simple as saying that if the invalid check happens _then_
>> undefined behaviour happens afterwards.
> Just to be clear, I agree that it can't hurt a correct program (except
> for the small cost of doing the checks).
>
> My concern was that for an incorrect program (which is the entire
> purpose of adding the checks) the results could be unpredictable. It
> might abort, which is the desired behaviour, or it might do something
> else and keep executing, and in that case it could be harmful for
> debugging because users would look at the source and think "well my
> iterators must be in range, otherwise that assertion would have
> failed, so the bug must be elsewhere".
>
> However ...
>
>> However, Google seem to find these checks useful, and you and Chris
>> are in favour, so let's keep them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vector_debug.patch
Type: text/x-patch
Size: 17537 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20151007/226d7202/attachment.bin>