Sun 28 Feb 2016 03:50:05 PM UTC, comment #13:
Everything works for me. Closing report.
|
Sat 27 Feb 2016 05:35:03 PM UTC, comment #12:
I checked in this additional change. It also reworks the original patch.
http://hg.savannah.gnu.org/hgweb/octave/rev/105224df2330
|
Fri 26 Feb 2016 08:08:58 PM UTC, comment #11:
@jwe: The patch works for the original reporter's case.
Do you want to close this report, or also deal with the assignin bug that Mike found? I'm not that bothered by it (see comment #3) and would let it pass.
Sample code
|
Fri 26 Feb 2016 06:33:56 PM UTC, comment #10:
I checked in the following changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/9ca194f7a858
|
Fri 26 Feb 2016 04:10:46 PM UTC, comment #9:
Ah, there is a bit of confusion there. Using "end" as an object index is not the same as "end" being a keyword to mark the end of a block of code (like a for loop) because in that context it is converted into a function call. We still need to prevent assignment to "end" in that context, but it can't be done at that point in the lexer. It needs to be done when the assignment statement is constructed. I'll see if I can fix this one.
|
Thu 18 Feb 2016 10:09:30 PM UTC, comment #8:
Thanks for taking charge of this, jwe.
I think the code already checks that the LHS of an assignment is not a keyword. The hitch is that the code to check if something is a keyword has a special case to ignore "end" in this context.
(When I made the comment about performance, I hadn't realised that the parser replaces all variable names with references to the particular symbol object; I assumed the identifier strings were processed at runtime.)
|
Thu 18 Feb 2016 05:11:00 AM UTC, comment #7:
I could be wrong, but I don't think it should be too hard to check that the LHS of an assignment is not a keyword. It should be possible to do this when the assignment expression is constructed, so there should be no performance penalty for evaluation.
|
Wed 17 Feb 2016 11:14:54 PM UTC, comment #6:
Anyone working on this may want to consider bug #33637 at the same time.
|
Sat 21 Nov 2015 03:46:03 AM UTC, comment #5:
Doing a complete check against all keywords in the interpreter would not only complicate the code but would also degrade performance.
In some ways, allowing assignment via assignin could be considered a useful feature. The assignment within the index brackets could/should be checked at parse time, IMHO.
I agree with Wolfgang that the end+1/end=1 typo bug is plausible enough to justify a fix, even if just a hack.
$0.02
|
Tue 17 Nov 2015 08:07:07 PM UTC, comment #4:
It could be source of octave code being difficult to debug when you don't expect such behavior. Simple typo will lead to e.g. a(end=1)=x instead of a(end+1)=x and no error is reported.
WF
|
Tue 17 Nov 2015 07:19:40 PM UTC, comment #3:
@Mike: The assignin() test seems to suggest that the check for keywords is being done at the parser level rather than at the level of the symbol table and interpreter. Maybe we need checking in both places, or maybe we should move all checks to a single location in order to avoid code redundancy. That location would have to be on the interpreter side as it walks through the tree of commands.
Or, we acknowledge that this is an oddity, because it seems like a lot of work to fix when it is a simple enough code construct to avoid.
|
Tue 17 Nov 2015 06:01:36 PM UTC, comment #2:
It appears that "end" and "for" can also be assigned via assignin:
although "for" still cannot be used as an index.
|
Tue 17 Nov 2015 05:24:27 PM UTC, comment #1:
Confirmed.
'end' is a reserved keyword and it shouldn't be possible to assign to it. This is the case at the command line as shown below. I also used another keyword, 'for' to show that in this case the interpreter is consistent and does not allow the assignment.
|
Mon 16 Nov 2015 08:52:26 PM UTC, original submission:
Whithin the bracketing of arrays the interpreter allows to assign a value to the "end" key word. Matlab does not allow this behavior (was only able to test with 2010a).
I was searching if this bug already has been reported but could not find a matchinng submit.
WF
|