#602 drivers lack controls over encodings

[Don Porter]

The typical Tcl_Channel may code into its
Tcl_DriverOutputProc() an assumption that
the bytes coming in are in a particular
encoding. Such a channel type will typically
include in its channel creation command
after a call to Tcl_CreateChannel() another
call to Tcl_SetOption() to set the initial
default encoding of the channel to what it
expects.

However, the Tcl_Channel system give the
driver no power to override, refuse, or
prevent a [chan configure] or equivalent to
set the encoding of the channel to a new value,
one inconsistent with the assumptions of the
OutputProc. The public routines necessary to
workaround this possible mismatch within
the OutputProc (read the current encoding setting
and convert to what's needed if needed) are
weak, and the resulting error prevention
stanzas are something every OutputProc concerned
about this issue would need to clumsily reproduce.

While these facts remain true, the implied position of
Tcl on channel encodings is that anyone using
[chan configure] to set an encoding takes responsibility
for any breakage induced.

Whenever an opportunity arises to consider the next
version of the Tcl_Channel driver interface, some
possible improvements to deal with this would be:

1) Routinely pass in the Tcl_Channel to driver routines,
rather than expect every driver to stick a field for it
into its ClientData.

2) A routine taking a Tcl_Channel that returns the
Tcl_Encoding(s) currently in use on that channel
without the need for the caller to do the ugly string
translations, lifetime management, etc, for itself.

3) A means by which a driver could refuse an encoding
change.