[Octave-bug-tracker] [bug #44779] copy-on-write, varargin, and classdef: invalid dimension inquiry of a non-existent value

[Michael Goffioul]

Follow-up Comment #1, bug #44779 (project octave):

I had a look at this one, hoping it would be trivial, but it's not. I know
what is happening, but I'm not sure how to solve it. jwe's input will probably
be needed.

The parser transforms this line:


p.parse (varargin{2:end})


into a parse tree structure using tree_index_expression (let's call it E1)
with the following type and arguments:


. => "parse"
( => tree_index_expression representing "varargin{2:end}" (let's call it E2)


When E1 is executed, the code in tree_index_expression::rvalue will split the
execution of the full indexed expression and first only execute the "." part.
This is because the code detects there's a magic "end", so it needs to execute
the index until (but not including) the magic "end", in order to apply this
magic "end" on the right value. There's a comment in that code that claims it
is related to handling expressions like "x{end}.a(end)", to process the second
"end" correctly, but this doesn't seem to be our case and I believe the
comment has just gone out of sync with the actual code.

What's happening is that because of the partial execution of the index
expression, the code ends up calling "subsref" on the object "p" with the
following arguments (note that it only contains the "." part):


. => "parse"


This is interpreted by the classdef code as being "p.parse()", that is calling
the method "parse" without any argument (indeed, "p.parse" and "p.parse()"
yields the same result for a method, for compatibility with Matlab). The
method "inputParser.parse" does not return anything, so the result is an
invalid object. This invalid object becomes the new current value being worked
on by the index expression and the code quickly choke on the fact that it's
undefined.

[jwe, if you could comment on the following, that'd be great]

At the core of the problem is the fact that E1 detects that is has a magic
"end". IMO the expression E1 does not have a magic "end". The magic "end"
applies to E2, not E1. Because of that, E1 tries to split the execution of its
index, while it shouldn't try to. In other words, should
tree_index_expression::has_magic_end really returns true when one of its
argument's has_magic_end returns true?


    _______________________________________________________

Reply to this item at:

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

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