[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deprecating --enable-bounds-check?
From: |
Rik |
Subject: |
Re: Deprecating --enable-bounds-check? |
Date: |
Thu, 11 May 2017 10:16:20 -0700 |
On 05/11/2017 10:07 AM, John W. Eaton wrote:
> On 05/11/2017 11:10 AM, Rik wrote:
>> 5/10/17
>>
>> jwe,
>>
>> What do you think about deprecating and eventually removing
>> --enable-bounds-check?
>
> It seems reasonable to me. We could make xelem, elem, and () all do the
> same thing, and deprecate xelem (and possibly elem, or is there an
> advantage to having both operator and member function forms?).
>
> Way back when, there were no tools like valgrind or the address sanitizer
> options for GCC (and no Clang at all). So I thought it made sense to add
> bounds checking as an option for the classes, even if it couldn't catch
> everything. You are right that now those tools are much better than the
> bounds checking we have, so we might as well just use them instead of
> trying to do a halfway job of it in the code.
Definitely no criticism. It was a different time, and now things have
changed for the better so we can clean up the code.
>
> Do we really need to deprecate the option? I guess we could keep the
> option but have it do nothing except print a message for a few releases.
> But I don't see any point in keeping the functionality at this point.
Just in case someone is using it, lets change configure.ac to print a
warning message that says they should configure with the address-sanitizer
option instead for detecting out-of-bound memory accesses.
>
> I'd also say that we should just standardize on using operator () instead
> of the elem method as well.
Without xelem, that is now possible and makes sense to me.
>
> Do you want to work on these changes or should I?
Why don't you go ahead if you have the time. I will continue, slowly, to
try and rationalize some of the #includes.
--Rik