This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: vector lightweight debug mode
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Christopher Jefferson <chris at bubblescope dot net>
- Cc: FranÃois Dumont <frs dot dumont at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 19 Sep 2015 10:08:57 +0100
- Subject: Re: vector lightweight debug mode
- Authentication-results: sourceware.org; auth=none
- References: <55F71189 dot 8080006 at gmail dot com> <20150914195038 dot GQ2631 at redhat dot com> <55F9C4F6 dot 6030706 at gmail dot com> <20150916202953 dot GE2631 at redhat dot com> <CA+jCFLueUi0Zo4m2D-scXNG5JLVSObKbJgXWaQRJrQ+notbXzg at mail dot gmail dot com> <CA+jCFLuiSYx02OH8UMubsOikPeTMR9sfukPESs1ureQu0WX0+Q at mail dot gmail dot com>
On 17 September 2015 at 21:52, Christopher Jefferson
<chris@bubblescope.net> wrote:
> ---------- Forwarded message ----------
> From: Christopher Jefferson <chris@bubblescope.net>
> Date: 17 September 2015 at 18:59
> Subject: Re: vector lightweight debug mode
> To: Jonathan Wakely <jwakely@redhat.com>
>
>
> On 16 September 2015 at 21:29, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 16/09/15 21:37 +0200, FranÃois Dumont wrote:
>>
>>>>> @@ -1051,6 +1071,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>>>> iterator
>>>>> insert(const_iterator __position, size_type __n, const
>>>>> value_type& __x)
>>>>> {
>>>>> + __glibcxx_assert(__position >= cbegin() && __position <= cend());
>>>>> difference_type __offset = __position - cbegin();
>>>>> _M_fill_insert(begin() + __offset, __n, __x);
>>>>> return begin() + __offset;
>>>>
>>>>
>>>> This is undefined behaviour, so I'd rather not add this check (I know
>>>> it's on the google branch, but it's still undefined behaviour).
>>>
>>>
>>> Why ? Because of the >= operator usage ? Is the attached patch better ?
>>> < and == operators are well defined for a random access iterator, no ?
>>
>>
>> No, because it is undefined to compare iterators that belong to
>> different containers, or to compare pointers that point to different
>> arrays.
>
> While that's true, on the other hand it's defined behaviour when the
> assert passes, and in the case where the thing it's trying to check
> fails, we are off into undefined-land anyway.
>
> A defined check would be to check if __offset is < 0 or > size(). Once
> again if it's false we are undefined, but the assert line itself is
> then defined behaviour.
That's a good point, but it still means an optimiser could remove the
checks, because it is impossible for them to fail in a correct
program.
That would be no worse than not having the checks at all, but it could
make them unreliable.