[Octave-bug-tracker] [bug #61472] AddressSanitizer crash in MEX tests

[John W. Eaton]

Follow-up Comment #47, bug #61472 (project octave):

tldr: It's probably best to defer the full fix for this issue until after
version 7, so for now let's just disable the std::pmr:... allocator by default
to avoid further delay for the release.

@Markus: I think the instantiation_guard was added long ago as a way to
prevent implicit instantiations, probably to speed up building Octave by not
having the compiler repeatedly instantiate the same templates many times.  But
I'm not sure whether that really matters?  If the full template definition is
not available to the compiler, instantiation is skipped anyway.

Today we should probably do this job with "extern template ..." declarations
for each type we want to explicitly instantiate.  Maybe that still makes sense
for an object like Array<T> that is so widely used.

What I would like to do (but is clearly too much for version 7) is

0 refactor the Array class so that the full definition is always available to
the compiler so that implicit instantiation can happen
0 maybe use extern template declarations and explicit instantiation for some
commonly used types (float, double, complex<float>, complex<double>, intN,
...)?
0 see whether we can allow Octave to be built with a C++17 compiler for
std::pmr::... and still build .oct files with C++11?

For the release, I suppose it reasonable to disable the std::pmr::... bits by
default.  But is that necessary for our Windows builds since we are building
with GCC 11 now?  Can't we just build everything with the (now default) C++17
mode and use the std::pmr::... allocator code?

BTW, I did try step 1 above but ran into some trouble with the instantiation
of the sorting functions.  Which then made me question whether we still need
to be using our own custom sort code (we stole it from Python quite some time
ago) or whether it would be OK now to use sorting functions from the standard
library.  I'm also thinking that we should follow what is done in the standard
library and eliminate the Array<T>::sort method in favor of an independent
sort function.  Standard library compatible iterators for Array<T> would also
make sense.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61472>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/