Check-in [77a2687054]

Login
Bounty program for improvements to Tcl and certain Tcl packages.

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: 77a2687054c366c9b85efc0f6a32610b030f0084d7dbd1436c8a34804b09d5ad
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
Hide Diffs Unified Diffs Ignore Whitespace Patch

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_,