Re: [clisp-list] help about [ clisp-Bugs-550603 ] UTF-16 min/max_ bytes_per_char mu st be 2

[Hoehle, Joerg-C. <Joe...@t-...>]

Sam Steingold wrote:
>> Sadly, min_bytes_per_char still looks like the solution - if
>> the slots were correct for all encodings, which they are obviously
>> not for UTF-16 (must be 2;2, but is 1;8 nonsense for UTF-16).
>
>this cannot be done properly for iconv-based encodings since there is
>no way to query libiconv for this information.
>I think these are set correctly for built-in encodings.

Sadly, having incorrectly set slots not only hinders WITH-FOREIGN-STRING, but also breaks other parts of the system which rely on correct information.


Example of another bug:
> (setf custom:*foreign-encoding* (ext:make-encoding :charset "ISO-8859-1"))
*** - SYSTEM::SET-FOREIGN-ENCODING: #<ENCODING "ISO-8859-1" :UNIX> is not a 1:1 encoding

This error is complete nonsense, "ISO-8859-1" is a 1:1 encoding we all know, except that CLISP checks the misdefined min/max_bytes_per_char slots of this external encoding and errors.

Obviously, having correct min/max is the "better" solution.

Microsoftian advice: "don't do that. Use :charset charset:iso-8859-1. Impnotes says that built-in encodings are preferred".


BTW, Impnotes says: "When an encoding is available as a built-in and through iconv(), the built-in is preferred, because it is more efficient and available across platforms."

I find this confusing, "preferred" by who?
Does that mean that CLISP automatically switches to an built-in one? Does that mean that the programmer ought to use built-in using charset:name instead of "name"?
I'd suggest a wording like: "..., we recommend using the built-in one, because ..."


Regards,
	Jorg Hohle.