ietf-822
[Top] [All Lists]

Re: 10646, UTF-2, etc.

1993-02-09 08:28:13
Untrue. 16 bit or 32 bit are not implementation details.
With 16 bit wchar_t, you can write
    array[(unsigned)char_code]

Not on my pdp11, you can't!

Are you saying your pdp11 is a major modern machine?

Plese do read and quote my mail appropriately.

        With 16 bit wchar_t, you can write

                array[(unsigned)char_code]

        and your program should work on most modern machines.
                                        ^^^^^^^^^^^^^^^^^^^^

Are you saying your pdp11 is a major modern machine?

But in any case, this misses the point.  You can always write code that
depends on details, if you try.  The point is that if you make a modest
effort to write clean code, then 16 bits vs 32 bits *is* a detail, one
that can be changed by changing a header file and recompiling.  Avoiding
a few inappropriate practices -- such as assuming that a particular
datatype is small enough to be usable as an array index -- suffices to
make code independent of this particular detail.

You are too much pedantic.

People in the real world does not think so.

Avoiding
a few inappropriate practices -- such as assuming that a particular
datatype is small enough to be usable as an array index --

Let me show a very convincing example.

It was the assumptions of Unicoders that a datatype for characters is
small enough to be able to be represented with 16 bits.

Now, the assumption was completely unfounded and totaly wrong in
several ways. But, how can you say that those who use Unicode do not
assume 16bitness for a datatype for characters?

For example, in poor Plan9 document, it is clearly documented that rune type
(the datatype for characters) is 16 bit.

So, poor Plan9 users don't have to make assumptions by themselves.
They just see document, which should make them write a PORTABLE
program.

                                                Masataka Ohta

<Prev in Thread] Current Thread [Next in Thread>