TIP 389: Full support for Unicode 10.0 and later (part 1)

Author:         Jan Nijtmans <[email protected]>
Author:         Jan Nijtmans <[email protected]>
State:          Final
Type:           Project
Vote:           Done
Created:        23-Aug-2011
Discussions-To: Tcl Core list
Keywords:       Tcl
Tcl-Version:    8.7
Tcl-Branch:     tip-389


This TIP proposes to add full support for all characters in Unicode 10.0+, inclusive the characters >= U+010000.


In order to extend the range of the characters to more than 16 bits, the type Tcl_UniChar is not big enough any more to hold all possible characters. Changing the type of Tcl_UniChar to a 32-bit quantity is not an option, as it will result in a binary API incompatibility.

The solution proposed in this TIP is to keep Tcl_UniChar a 16-bit quantity, but to increase the value of TCL_UTF_MAX to 4 (from 3). Any conversions from UTF-8 to Tcl_UniChar will convert any valid 4-byte UTF-8 sequence to a sequence of two Surrogate characters. All conversions from UTF-16 to UTF-8 will make sure that any High Surrogate immediately followed by a Low Surrogate will result in a single 4-byte UTF-8 character.

This can be done in a binary compatible way: No source code of existing extensions need to be modified. As long as no characters >= U+010000 or Surrogates are used, all functions provided by the Tcl library will function as before. There are few functions which currently return a value of type Tcl_UniChar, those will be modified to return an int in stead.


As Unicode 10.0, and future Unicode versions, will supply more and more characters outside the 16-bit range, it would be useful if Tcl supports that as well.


This document proposes:


As long as no Surrogates or characters >= U+010000 are used, all functions behave exactly the same as before. The only way that Tcl_UniCharToUtf can produce a 4-byte output is when Surrogates or characters >= U+010000 are used.

Extension that want to be compatible with any Tcl version, can include tcl.h as follows:

#define TCL_UTF_MAX 4
#include <tcl.h>

or they can call the C compiler with the additional argument -DTCL_UTF_MAX=4, in order to be sure that UTF-8 representations of length 4 can be handled. This way, the extension can be used with any Tcl version, whether it supports Surrogates or not.

Apart from this, it is advisable to initialize the variable where the chPtr argument from Tcl_UtfToUniChar points to, as this location is used to remember whether the High Surrogate is already produced or not. Not doing so when the first character of a string is a character > U+010000 might result in a Low Surrogate character only. This danger, however unlikely, only exists for the first character in a string, and it only occurs when the (random) value is exactly equal to the expected High Surrogate.


In the current implementation "string length \U10000" will return 2 in stead of the expected 1. The reason for this is that many internal operations convert the representation into UTF-16 format, which occupies two surrogate characters. This should change in future Tcl implementations. Correcting this would involve many internal changes, and the risk of introducing crashes because of miscounting bytes (as have been reported in the past, during the tip-389 branch implementation development). Tcl is not the only language doing it this way: javascript does it as well.

This also means that functions line "string index", "string range" and "string reverse" might give unexpected results when characters > U+010000 are involved. Any index pointing to the middle of a 'double-length' Unicode character will be handled as if the index points to just after the character instead. So:

In Tcl 8.7 with TIP #389:

% string length "a\U100000b"
% scan %c \U100000
1048576  -> (this is the correct Unicode character)
% string length [string index "a\U100000b" 1]
2        -> (the Unicode character has length 2)
% string length [string index "a\U100000b" 2]
0        -> (So we cannot access the lower surrogate separately)

So, the "string length" of a Unicode character >= U+010000 is 2, and if you try to split it in two separate characters that won't work: It will then be split in a character with length 2 (the original one) and another character with length 0 (the empty string).

Also note that the regexp engine still cannot really handle Unicode characters >U+FFFF, it will handle those as if they consist of 2 separate characters. Most usage of regular expressions won't notice the difference.

Those caveats are planned to be handled in "part 2" (TIP #497)

Reference Implementation

A reference implementation is available in the tip-389 branch.

Rejected Alternatives

It would have been possible to give the new Tcl_GetUniChar and friends a new stub entry and to deprecate the original one, as was done with Tcl_Backslash. However, Tcl_Backslash originally only returned an ASCII character, which needed to be extended to UniChar. UniChar's < U+01000 common in Tcl, Unicode Characters >= U+010000 are rare and don't behave well in Tcl 8.6 anyway. Casts from Tcl_UniChar to int don't cause a warning because all Tcl_UniChar's fit in the 32-bit int range. On the other hand, casting "char" to Tcl_UniChar can result in surprising Unicode characters U+FF?? if char is a signed type (as in most platforms). That's why Tcl_Backslash had to be handled differently.


This document has been placed in the public domain.