Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Complete draft of TIP 502. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
9b46106ae0439f45af826f324c09a26c |
User & Date: | dgp 2018-03-30 16:04:05.588 |
Context
2018-03-30
| ||
16:07 | Formatting fixes. check-in: 77a2687054 user: dgp tags: trunk | |
16:04 | Complete draft of TIP 502. check-in: 9b46106ae0 user: dgp tags: trunk | |
2018-03-26
| ||
19:03 | IMplementation now on the branch. check-in: a159e3a950 user: dgp tags: trunk | |
Changes
Changes to tip/502.md.
︙ | ︙ | |||
16 17 18 19 20 21 22 | Many Tcl programmers may be surprised by this result % lindex {a b} -4294967295 b This is the consequence of two features of incumbent Tcl | | > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > | 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | Many Tcl programmers may be surprised by this result % lindex {a b} -4294967295 b This is the consequence of two features of incumbent Tcl functionality. First, passing the value *-4294967295* to _Tcl\_GetInt\(FromObj\)_ results in a successful extraction of the C __int__ value __1__. Generally any supported formatting of any value between __-UINT\_MAX__ and __UINT\_MAX__ is accepted, but transformed into a value between __INT\_MIN__ and __INT\_MAX__. Second, the internal routine/macro _TclGetIntForIndex\(M\)_ implements a definition of Tcl index values where any value acceptable to _Tcl\_GetInt\(FromObj\)_ is also acceptable as an index of the same value. Both of these features are of questionable merit, but the first has a fair bit of compatibility constraint attached to it because it involves the behavior of public routines. The second should be more open to potential revisions. Another source of possible surprise is demonstrated: % lindex {a b} 4294967295 % lindex {a b} 4294967295+1 a % lindex {a b} 4294967296 bad index "4294967296": must be integer?[+-]integer? or end?[+-]integer? These examples illustrate overflow effects in index arithmetic, and a rejection of apparently valid integer values that are larger than UINT_MAX. Neither of these effects is in agreement with handling of integers by **expr** which makes the results surprising. # Proposal Revise the parsing of values used as index values to accept all integer representations acceptable to **expr** as either complete index values or as operands in the end-offset or index arithmetic formats. Although this suggests an unlimited range of valid index values, in practice all index values will be truncated to the signed wide integer range, __LLONG\_MIN__ to __LLONG\_MAX__, internally, and in the Tcl 8 series of releases, further truncated to the signed int range, __INT\_MIN__ to __INT\_MAX__, since no container can be larger than that range in Tcl 8. # Compatibility Examples like the ones in the Background above will incompatibly change from one successful outcome to a different successful outcome. This is a true incompatibility, but it is difficult to believe any actually desires outlier behaviors illustrated above, much less has code that relies on them. # Implementation Drafted on the tip-502 branch. Note that the core routine of the implementation, _GetWideForIndex_, produces a *Tcl_WideInt* result from a successful parse. I expect this functionality will be useful in the Tcl 9 codebase as an enabling step for containers with sizes larger than __INT\_MAX__. The existing internal routine _TclGetIntForIndex_ continues to produce the more limited range suitable for Tcl 8. # Copyright This document has been placed in the public domain. |