[Octave-bug-tracker] [bug #47676] Error applying multiplication-assignment operator to variable defined in script

[Lachlan Andrew]

Update of bug #47676 (project octave):

                Severity:              3 - Normal => 4 - Important          

    _______________________________________________________

Follow-up Comment #5:

JWE, your example


foo -bar


is really serious.  If a script sets


foo = ones (100,100);
-verbatim+

then


foo /2


gives [1,1] -- a totally incorrect result with no errors or warnings raised. 
Fortunately the size of the result is not the size of foo and so an astute
observer would guess something is wrong -- but what if the size of foo was not
known in advance?

To me, this is more than "really unfortunate".  Giving an "incorrect result"
without an error is as bad as it gets -- if they occur frequently, no-one can
trust results that Octave produces.  I have requested before that we have a
separate tracker Item Group for this type of silent but serious error.  I've
raised the severity of this bug report; I hope that is OK.

One way to solve the worst bug is to be cautious when using character
expressions to index an array.  If a character is used to index an array and
the first few characters could be an operator, the file could be re-parsed
(somehow remembering where we are up to...) or at least a warning could be
given.

Another option would be detect when new variables are added by a script and
reparse the file when they are.  That will have a performance penalty, but
there are two cases:

1. scripts are not called very often, in which case the cost is low

2. scripts are called often, in which case the seriousness of the bug is high
and so even an expensive solution is warranted.


Regarding the issue of Matlab incompatibility, I think that "/=" is the most
serious since it could easily be part of a file name.

(file #36921)
    _______________________________________________________

Additional Item Attachment:

File name: example_2.m                    Size:0 KB


    _______________________________________________________

Reply to this item at:

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

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