bugGNU Octave - Bugs: bug #46459, Interpreter allows number...

 
 

bug #46459: Interpreter allows number assignment to "end" key word within array brackets

Submitted by:  None
Submitted on:  Mon 16 Nov 2015 08:52:26 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: John W. Eaton <jwe>
Originator Name: Wolfgang F.Originator Email: -unavailable-
Open/Closed: ClosedRelease: 4.0.0
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 28 Feb 2016 03:50:05 PM UTC, comment #13:

Everything works for me. Closing report.

Rik <rik5>
Project Administrator
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

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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

Rik <rik5>
Project Administrator
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

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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.)

Lachlan Andrew <lachlan>
Project Member
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.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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.

Lachlan Andrew <lachlan>
Project Member
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

Lachlan Andrew <lachlan>
Project Member
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

Anonymous
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.

Rik <rik5>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

Rik <rik5>
Project Administrator
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

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 28 Feb 2016 03:50:05 PM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 26 Feb 2016 06:33:56 PM UTCjweStatusConfirmed=>Ready For Test
    Thu 18 Feb 2016 05:11:00 AM UTCjweAssigned toNone=>jwe
    Tue 17 Nov 2015 05:24:27 PM UTCrik5StatusNone=>Confirmed
      Operating SystemGNU/Linux=>Any

    Back to the top


    Powered by Savane 3.1-cleanup1