Overview
Artifact ID: | 0e22c8c9271bee0c988a790adc1aa02d9dcd3002c5286b72a3a85a4d564848eb |
---|---|
Ticket: | 9dfae3413d66da5252296c923fff8a0bde59d45d
interp limit commands still seems to be 32 bits |
User & Date: | sbron 2025-06-25 20:47:02 |
Changes
- assignee changed to: "nobody"
- closer changed to: "nobody"
- cmimetype changed to: "text/x-markdown"
- comment changed to:
After running for quite some time, some interp in my program has executed 2147000000. As the interp doesn't seem to be misbehaving, I would like to increase its command limit by another 1000000. That results in an error: "command limit value must be at least 0" This happened on Tcl 8.6.14, so I thought to test in the latest 9.0 as that changed "everything" to 64 bits. But to my dismay I could still easily reproduce the error: ``` % [interp create] limit commands -value 2148000000 command limit value must be at least 0``` The manual page for Tcl_LimitSetCommands() does indicate that commandLimit is of type Tcl_Size. But the reverse function, Tcl_LimitGetCommands() is still documented to return an int. Diving into the source code, I see that Tcl_LimitGetCommands() actually returns a Tcl_Size, as I would have expected. However, I also find that ChildCommandLimitCmd() calls Tcl_LimitSetCommands() with variable `limit`, which is still an int!
- foundin changed to: "54eb90319d"
- is_private changed to: "0"
- login: "sbron"
- priority changed to: "5 Medium"
- private_contact changed to: "8475f421649231f1e116ac602bea4537d2b027b4"
- resolution changed to: "None"
- severity changed to: "Important"
- status changed to: "Open"
- submitter changed to: "sbron"
- subsystem changed to: "20. [interp]"
- title changed to: "interp limit commands still seems to be 32 bits"
- type changed to: "Bug"