[Top][All Lists]

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

Re: should Octave be more strict about checking number of arguments?

From: John W. Eaton
Subject: Re: should Octave be more strict about checking number of arguments?
Date: Sun, 12 Jul 2020 17:57:57 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 7/8/20 9:22 PM, Kai Torben Ohlhus wrote:
On 7/9/20 1:28 AM, John W. Eaton wrote:
Bug report 58695 raised the following issue.

Currently, Octave allows function to be called with more input or output
arguments than can possibly be used or created.  For example,

   function f (), end

may be called as

   f (1)


   x = f ()   ## You do get a warning here
   [1, f, 2]  ## But not here...

I think the original intent in Octave was to allow the call warn or
attempt to do something reasonable (if possible) when no outputs are
created.  So I could see a reasonable argument made for allowing this
kind of behavior but I don't know why I thought this was a good thing to
do and it seems reasonable to have the interpreter detect these types of
argument number mismatches automatically.

I think Matlab always throws an error if a function is called with more
input or output arguments than can possibly be used or generated so this
would improve compatibility somewhat.

Should we change Octave's behavior to match Matlab?  Always?  Just when
using --traditional mode?


Previously, I tried to fix bug #58686, where a scenario showed up, that
should always make Octave follow the Matlab approach in this regard.

The short outline is, assert() can be called in two ways

    assert (expr)
    assert (val, expected)

Now I made a test like this with your example

    assert (f(1), 42)

Because f() returns nothing the call was (without warning or error)
interpreted as

    assert (42)  ==  assert (true)

and passed Octave's test suite en perfect, even my function did not work
at all.

Thus with silent argument ignoring it is easily possible to create super
trivial mistakes, which are a nightmare to detect and to debug as the
code grows and Octave's test suite is of no help then.

I vote to always follow the behavior of Matlab in this case or at least
to throw a warning.

I pushed the following changesets to default:


The first makes is an error to call a function with more inputs or outputs than the function can accept or produce. The second fixes Octave functions and tests to avoid these errors. The third change fixes tests that expect an error to match the new "function called with too many inputs/outputs" error message instead of the older "invalid function call" error.

This change is probably too disruptive for stable, but applying it now on default should give us time for testing before version 7 is released. If it causes too much trouble, we can generate a warning instead of an error by default.


reply via email to

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