Check-in [9b46106ae0]

Login

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: 9b46106ae0439f45af826f324c09a26c76dbf9e946aa2caef0735c5774dd44d0
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
Unified Diff Ignore Whitespace Patch
Changes to tip/502.md.
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

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?






# Proposal













# Compatibility







# Implementation

Taking shape on the tip-502 branch.








# Copyright

This document has been placed in the public domain.








|




















>
>
>
>



>
>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
>



|
>
>
>
>
>
>
>





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.