D 2014-10-02T12:15:45.893
L Encoding\sSystem
P cdff0ff2368e1118e7cc3a09b6b199e7a30b859d
U dgp
W 2895
<h1>Source Files</h1>
* portions of [/finfo?name=generic/tclEncoding.c|tclEncoding.c]
<h1>Public Interface</h1>
* struct Tcl_EncodingType
* Tcl_CreateEncoding
* <i>Tcl_GetEncoding</i>
* Tcl_FreeEncoding
* Tcl_GetEncodingName
* <i>Tcl_GetEncodingNames</i>
* Tcl_SetSystemEncoding
* Tcl_ExternalToUtfDString
* Tcl_ExternalToUtf
* Tcl_UtfToExternalDString
* Tcl_UtfToExternal
<h1>Private Interface</h1>
* TclInitEncodingSubsystem
* TclFinalizeEncodingSubsystem
<h1>Directly Depends On Public Interface</h1>
* [Hash Tables]
* [Threads]
* [Dynamic Strings]
* [UTF-8 String]
* [Allocation]
<h1>Directly Depends On Private Interface of</h1>
* <i>None</i>
<h1>Discussion</h1>
This is the foundational layer of encoding operations in Tcl.
The routines <b>Tcl_GetEncoding</b> and <b>Tcl_GetEncodingNames</b>
are the source of dependency tangles, as they automatically route some of
their function to the [Encoding Loading] layer, which has far more dependencies,
some circular. A more conditional approach can disentangle this, notably
in the init and teardown sequences.
The fundamental function here is to associate an ASCII string as the name
of each encoding. The names used by Tcl are unfortunately a rather ad hoc
set and don't seem attached to any standard naming system. One difficulty
to resolve is the role of case in encoding names. The attachment of encoding
names to encoding data file names established in [Encoding Loading] and the
concern about filesystems that handle case in filenames in unexpected ways
is at issue here, as well as just the general possibility for confusion. So,
better names and clearer case rules would be good.
The encoding/decoding functions in the extension struct <b>Tcl_EncodingType</b>
are the guts of operations, and the interface functions determine the interfaces.
Changes here will be difficult incompatibilities, but may still be worth pursuing
because the existing <b>Tcl_*To*</b> set of functions really doesn't mesh well
with the needs of actual callers. See the use of this routines by the [Channel System]
to see the trial and error involved. Some revisions that made available interfaces
that delivered what callers need would be an improvement. The most glaring defect
is that there is no way to direct the <b>Tcl_ExternalToUtf*</b> routines to respect
a limit on the number of chars produced.
Any reforms in Tcl string values generally will likely have an impact here as well.
Another audit of the refcounting scheme employed here wouldn't hurt, with particular
attention to thread safety issues.
Some routines take a (<b>Tcl_Interp *</b>) argument, for error reporting,
though they accept a value of NULL.
This reduces the degree to which these routines might be used separately from
the rest of Tcl.
Z 042b2888b91bca6a8296e177c87af5bf