[Octave-bug-tracker] [bug #53156] examples/code/make_int.cc produces a segfault at exit of Octave

[Dan Sebald]

Follow-up Comment #13, bug #53156 (project octave):

I saw the changeset in the log:

http://hg.savannah.gnu.org/hgweb/octave/rev/5f445419559f

and wondered about the strange comment.  Seems to be making things fragile to
the point that future programmers will avoid a proper fix or even know to look
for a bug because it's covered up.  (Also, I think there may be some
compiler/OSes that complain at exit if there is some unfreed memory. 
Microsoft and latest Windows systems comes to mind.)  Is there a crash prior
to this make_int.cc for some other example?  Or is it only this code where
there is a known crash?  Maybe it is the code.

In that regard, looking at what's attached to this bug report, just a couple
questions from a consistency standpoint.  I see in the make_int.cc


DEFUNOP_OP (gnot, integer, !)
DEFUNOP_OP (uminus, integer, -)
DEFUNOP_OP (transpose, integer, /* no-op */)
DEFUNOP_OP (hermitian, integer, /* no-op */)

[snip]

      INSTALL_UNOP_TI (ti, op_not, octave_integer, gnot);
      INSTALL_UNOP_TI (ti, op_uminus, octave_integer, uminus);
      INSTALL_UNOP_TI (ti, op_transpose, octave_integer, transpose);
      INSTALL_UNOP_TI (ti, op_hermitian, octave_integer, hermitian);


There is a consistency there in the way what looks like four operators are
defined.  Yet, looking at the implementations of these operators there is


  octave_value gnot (void) const { return octave_value ((double) ! scalar); }

  octave_value uminus (void) const { return new octave_integer (- scalar); }

  octave_value transpose (void) const { return new octave_integer (scalar); }

  octave_value hermitian (void) const { return new octave_integer (scalar); }


which isn't consistent.  One operator does not make use of "new" while three
of them do.

Higher in the header portion of the patch is use of a "new"


  octave_base_value * clone (void) { return new octave_integer (*this); }


which makes sense to me that it return a pointer because of the "new"
operation, while three operators mentioned above aren't returning pointers.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53156>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/