Re: Deprecating --enable-bounds-check?

[Rik]

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