Description

markshannon

opened on Feb 27, 2023

Issue body actions

Either the tool needs to reject all explicit gotos, or it needs to understand them.
Rejecting them all seems easier, and not that much of a burden on the user.

Example of incorrectly generated code: #102287

Activity

1. markshannon

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Feb 27, 2023
2. markshannon

   assigned

   gvanrossum

   on Feb 27, 2023
3. gvanrossum commented on Feb 27, 2023

   

   gvanrossum

   on Feb 27, 2023

   Member

   More actions

   It's not that simple. If the user code wants an error exit before it has DECREF'ed all its stack inputs, it must use goto error, otherwise the stack values are leaked. OTOH all error exits after the inputs have been DECREF'ed must use ERROR_IF(), else the values will be double-DECREF'ed.

   In order to properly implement the behavior you ask for, the generator would have to understand all forms of DECREF, so it can track what is the correct way to exit. If we insist there are no "bare goto error" statements, we will need to rewrite ~50 instructions to get rid of those one way or another (probably inserting extra DECREFs).

   (I counted and there are nearly 100 ERROR_IF() calls but nearly 50 goto error statements, in Python/bytecodes.c.)
4. iritkatriel

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Nov 28, 2023
5. markshannon commented on Jan 11, 2024

   

   markshannon

   on Jan 11, 2024

   MemberAuthor

   More actions

   bytecodes.c now only contains gotos to a small set of special labels, which seems fine for correctness.
   The only exception is CALL_LIST_APPEND which does its own refcount handling.
   I think we can tolerate one special case.
6. markshannon

   closed this as completedon Jan 11, 2024

Issue actions