[Top][All Lists]

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

[Octave-bug-tracker] [bug #53156] examples/code/make_int.cc produces a s

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53156] examples/code/make_int.cc produces a segfault at exit of Octave
Date: Tue, 20 Feb 2018 19:43:06 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

I saw the changeset in the log:


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 */)


      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:


  Message sent via/by Savannah

reply via email to

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