Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

[Donal F. <don...@ma...>]

In this case, the branch is effectively starting from the point where the conversion to Tcl_Size has already taken place internally in the compiler; it's just renaming some of them so that I could better see what was going on. The aim was that I'd be able to look up the definition of a variable being used as, say, a jump offset and see that it isn't also being used for variable indices and/or aux data indices.

The range checks are for ensuring that the value read by TclGetUInt4AtPtr (widespread in the bytecode engine) is matched by the range checks in the compiler (where the values are [0,UINT_MAX] plus -1 for no index, which fits Tcl_Size nicely). Fixing the opnd variable usage within the bytecode engine is something for another branch I think; there's a lot of mixed usage where we ought to do something a bit more type-correct. But that's a bug already in the bytecode engine so I'm not condemning this branch to resolve it!

Donal.
________________________________
From: apn...@ya... on behalf of apn...@ya...
Sent: Wednesday, May 14, 2025 17:31
To: Donal Fellows; 'Tcl Core'
Subject: RE: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)


I’m really not worried about LVT indices, it just happened to be the first (and only) range check that showed up in the diffs. The bigger issue is that these range checks appear in lots of places and any of them could have similar repercussions. I feel changing the limit to UINT_MAX from INT_MAX has limited value and not worth the risk of fiddling with TEBCResume to *selectively* split the signed and unsigned use cases. And as discussed ad naseum in the Tcl_Size discussion, modifying types from signed->unsigned is not to be taken lightly.