Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Formatting fixes. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
77a2687054c366c9b85efc0f6a32610b |
| User & Date: | dgp 2018-03-30 16:07:50 |
Context
|
2018-03-30
| ||
| 17:55 | New TIP 506 check-in: c80f0474ca user: dgp tags: trunk | |
| 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 | |
Changes
Changes to tip/502.md.
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
..
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
|
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
................................................................................
% 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_,
|
|
|
|
|
|
|
|
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
..
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
|
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
................................................................................
% 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 internally to the
signed wide integer range, __LLONG\_MIN__ to __LLONG\_MAX__, 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 anyone
actually desires the 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_,
|