🚀 go-pugleaf

In article <1in2c8INNmbj@life.ai.mit.edu>
	glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:

>One should not in general use an interchange code (UTF1 or UTF2) for
>processing.  While one may use a process code for interchange,

That is opposite.

One can use interchange code for processing if it is convenient.

There is no problem in doing so, as each application knows every detail
of how interchange code is.

On the other hand, one can't use process code for interchange, unless
you are living in the closed world, because other applications won't
accept it.

>(e.g., Unicode and 10646 UCS[24] allow NULL bytes and ISO2022 C0/C1 control
>code bytes in any byte position of their "process codes").

That is one of famous fatal design flaw of it.

>I can't imagine why anyone in their right mind would want to use UTF[12]
>or any other ostensibe interchange code for processing, given the problems
>of variable length encodings.

Maybe, you can't. But, in many cases, variable length is of no problem.

>But if one is to create
>an aware application which uses more than the ASCII subset, or if it is
>to memory map files, then use of a fixed-with process code (even for backing
>store) becomes much more sensible.

You should be crazy. If you are mapping a file under possibly networked
environment (these days, all environments are so), you can't use multiple
octet fixed width code because of endeaness. Don't say signature, because
it makes everything complex and, thus, slow, and your reasoning to map
files should be for efficiency and for simplicity. BTW, though file mapping
is neither efficient nor simple, it is another topic.

						Masataka Ohta