octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Deprecating --enable-bounds-check?


From: Rik
Subject: Deprecating --enable-bounds-check?
Date: Thu, 11 May 2017 08:10:54 -0700

5/10/17

jwe,

What do you think about deprecating and eventually removing
--enable-bounds-check?

The current situation is that all of liboctave has Octave's own internal
bounds checking mechanism.  It is implemented around a #define selected by
--enable-bounds-check and defaults to being disabled.  Example code from
dim-vector.h shows how it works in practice.

  // Fast access with absolutely no checking

  octave_idx_type xelem (int i) const { return rep[i]; }

  // Safe access to to elements

  octave_idx_type elem (int i) const
  {
#if defined (OCTAVE_ENABLE_BOUNDS_CHECK)
    assert (i >= 0 && i < ndims ());
#endif
    return xelem (i);
  }

There are two philosophical issues for me.  First, I would prefer to use
standard, pre-existing blocks of code wherever possible rather than
handrolling our own.  In this case, if memory violations are a potential
issue then maybe the particular user should just use
--enable-address-sanitizer-flags and use an already proven, lightweight
bounds checker.  There was also talk of expanding the configure script to
easily allow the sanitizer to check other options besides just addresses.

The second issue is that it complicates the API to have both elem() and
xelem() functions.  Because we really do want to favor efficiency in the
core there are many times where a programmer has to carefully consider
which function to use.  That's tedious, and what if the programmer gets it
wrong?  It seems preferable to just have a single elem() function for the
API.  Also, the index operator () is currently aliased to elem().  This is
nice because it produces readable C++ code that looks like m-file code. 
For example,

for (octave_idx_type i = 0; i < x.numel (); i++)
  x(i) = 1.0;

But right now, this is coded for performance as

for (octave_idx_type i = 0; i < x.numel (); i++)
  x.xelem (i) = 1.0;


Thoughts?

--Rik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]