octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #59704] function call on classdef subobject fa


From: Fernando
Subject: [Octave-bug-tracker] [bug #59704] function call on classdef subobject fails with "numel: invalid return value"
Date: Sat, 2 Jan 2021 10:24:53 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Follow-up Comment #6, bug #59704 (project octave):

This bug is related to bug #58727. It's again the problem of ignoring a
function return value because "~" appears in the lvalue list of the current
instruction. In that case, it happened while evaluating an argument list, and
in this case, it happens when evaluating numel for an lvalue.

The solution proposed (comment #4) is basically the same used for that bug:
temporarily set the lvalue list to null. However, in this case, this can be
done in different moments of the evaluation:
- as soon as octave_lvalue::numel is called (although it might not be
necessary).
- as late as possible, and only when a user-defined numel function is being
called.

I chose the second option, just to avoid unnecessary overhead.

I have also detected the same problem in another situation: evaluating
overloaded subsasgn. I don't know if this should be a separate bug. For
example (using the file class_subsasgn attached):


>> obj=class_subsasgn();
>> obj(:)
ans =
   1001
   1002
   1003
   1004
   1005

>> [x,obj(1)]=size(rand(2,5)); % This works without problems
>> obj(:)
ans =
      5
   1002
   1003
   1004
   1005

>> [~,obj(1)]=size(rand(2,5)); % But this does not work
error: cannot convert 'scalar' into 'object'


In this case, the output of overloaded subsasgn is being ignored.

This can also be solved in the same way. It could also be done early in the
evaluation process, or later, and only if user-defined subsasgn is being
called (in octave_classdef::subsasgn).

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Mensaje enviado vía Savannah
  https://savannah.gnu.org/




reply via email to

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