bugGNU Octave - Bugs: bug #59265, Partial assignment of outputs for...


bug #59265: Partial assignment of outputs for some error conditions

Submitter:  Rik <rik5>
Submitted:  Wed 14 Oct 2020 01:14:33 AM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Wed 14 Oct 2020 02:52:18 PM UTC, comment #2: 

Since this is a rather weighty topic, should it be shifted to Discourse and leave this bug report as a reminder that something needs to be done?

I don't have access to Matlab to check on MEX functions, but I suspect you're right that no checking is possible unless it is put in to the code itself.

So one solution---which would be consistent across Octave built-in functions, .oct files, and .mex files---would be for the function itself to always check nargin and nargout and issue an error message.  We would want to agree on the standard form of the error message, and probably even make it a standard function in errwarn.cc, so that the same message is reliably produced.

Another approach would be to start tinkering with the DEF macros for function declaration.  Presumably we could figure out a way to gracefully continue to use people's existing code.  I.e., if they were using the old form of the macro the interpreter would assume the equivalent of varargout and varargin and not perform any verification.

I'd want to understand more about the last solution of changing the functions to look like methods before going down that route.

We've identified three possible solutions.  Are there others we should look at before we decide to really examine the merits of each?

Rik <rik5>
Group administrator
Wed 14 Oct 2020 03:47:07 AM UTC, comment #1: 

What happens for MEX functions in Matlab, where I think there is no way to declare to Matlab the maximum number of outputs that may be produced?

I do agree that we could add this info to the DEFUN declarations for functions that produce a maximum number of output values.

Also, we could declare the types of arguments that the built-in functions can handle so they can be dispatched the same way as class methods.  I started working on that at one point, but did not make progress on actually tagging the functions.  See, for example the DEFUNs for svd, disp, fdisp, and display.

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 01:14:33 AM UTC, original submission:  

Sample code:

[a,b] = newline ()
error: element number 2 undefined in return list
a =

double (a)
ans = 10

The newline() function only produces one output so I would expect that since this is an incorrect way to call the function I would get an error.  This is what Matlab does.  It throws an error about calling newline() with too many output arguments.

Note that the correct error is thrown if the function is defined in an m-file.  Consider the following newline2.m function

function retval = newline2 ()
  retval = "\n";

When called from the command line

[a,b] = newline2 ()
error: newline2: function called with too many outputs
error: called from

So the problem is only exhibited for built-in C++ functions.  For reference, the code for newline in strfns.cc is

  if (args.length () != 0)
    print_usage ();

  static octave_value_list retval = ovl ("\n");

  return retval;

It would seem that either C++ code needs to explicitly check nargout (which means modifying lots and lots of functions), or we need to communicate to the interpreter via the DEFUN macro how many output arguments are expected and have the interpreter check that.  The second approach also requires lots and lots of changes.

Rik <rik5>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-14 rik5 Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code