#2122 Inconsistent treatment of encoding names

[Michael Schlenker]

I noticed a slight inconsistence in the way [encoding
names[ and fconfigure $fid -encoding work together.

[encoding names] returns all encoding names in lowercase.

fconfigure $fid -encoding encodingname

accepts most encoding names in lower _and_ upper or
mixedcase. Only the following are excluded from this
special behaviour:

UTF-8
UNICODE
IDENTITY

Test script:

foreach enc [encoding names] {
catch {fconfigure stdout -encoding $name} msg
append text $msg
catch {fconfigure stdout -encoding \ [string toupper $name]} msg
append text $msg
}
set text

Tested on win2k,sp2

Michael Schlenker

[Donal K. Fellows]

Logged In: YES
user_id=79902

This is platform-specific behaviour caused by the fact that
Windows does not (normally) treat files as having case
sensitive names. Essentially, what happens is that whenever
you ask for a currently unknown encoding, Tcl tries to load
the appropriate encoding definition file from its library
directory (hunt around; I'm sure you can find it) and that
succeeds because Windows is just case-preserving, not
case-sensitive. On the other hand, the only encodings that
we *guarantee* to support are those returned by [encoding
names], which is not really much more than the results of a
glob of that lib dir.

Note that the encodings "utf-8", "unicode" and "identity" are
special, in that they are handled internally. Indeed, those are
the encodings that Tcl actually uses for its internal string
handling. Because they are handled internally, they have no
associated encoding files and any attempt to load (for
example) UNICODE.enc will fail.

Jeff, would you agree with me that this is therefore an invalid
bug?

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

Donal is correct. In any case, encoding names should be
considered the reference for names available.