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

[John W. Eaton]

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

My intent was never to force a switch to require a C++17 compiler even if
Octave is built with one.

My original change used std::pmr::memory_resource conditional on


#if __cplusplus >= 201703L


which I understood to be sufficient to detect this feature.  Using this
conditional, I think Octave could be compiled with a C++17 compiler that
supports std::pmr::polymorphic_allocator and then also allow .oct files to be
built with -std=c++11.

But then there were reports that some compilers lie about their support for
C++17 features and fail to compile code using std::pmr::memory_resource even
though the __cplusplus >= 201703L test succeeds.

So how about doing the following instead?  In Octave, we can use


#if __cplusplus >= 201703L && ! defined
(OCTAVE_DISABLE_STD_PMR_POLYMORPHIC_ALLOCATOR)


We can check whether the compiler used to build Octave is lying about
supporting C++17 and disable this feature automatically when building  Octave
but *DO NOT* define OCTAVE_DISABLE_STD_PMR_POLYMORPHIC_ALLOCATOR in
octave-config.h.  Then if Octave is compiled with a proper C++17 compiler, we
use this feature internally.  But if a .oct file is compiled with -std=c++11,
we fall back on using std::allocator.  This choice should not affect pure MEX
files because the Array interface is not exposed in the MEX interface.

If your compiler lies to you and defines __cplusplus to be 201703L or later
but doesn't support std::pmr::polymorphic_allocator, you can define
OCTAVE_DISABLE_STD_PMR_POLYMORPHIC_ALLOCATOR yourself (command line or in your
code prior to including Octave header files).

Would this solution work?

If I understand correctly, a conforming compiler should also define
__cpp_lib_memory_resource if it has the <memory_resource> header, so maybe we
should also use that macro in some way?  Or should it be sufficient to use the
value of __cplusplus alone?

    _______________________________________________________

Reply to this item at:

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

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