Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0018.txt

Text File | 1992-02-21 | 4.1 KB | 73 lines

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (John F Haugh II) writes:
>I would say that POSIX completely ignored any codeset which was not
>7-bit clean ASCII.  The simple issue of 8-bit code points being
>mangled by ISTRIP is clear proof of this point.  The definition of
>this function is in terms of bit widths, rather than character sizes.
>Any 8-bit code set (such as the European character sets or even EBCDIC)
>are mangled by the translation suggested by ISTRIP.
>
>I am certain that the various groups did give some thought to the
>issue, but it really is pretty obvious that 1003.1 completely ignored
>any system which uses 8 bit character sets.
>
>While 1003.1 was off inventing a new tty subsystem, it would have
>been nice if they invented an interface for setting any locale-specific
>traits of the tty system (a "tcsetlocale()" sort of deal) that would
>provide for translations of locale-specific characters (the variously
>accented vowels, for example) into something more POSIX-friendly.

How utterly off the mark can you be?  ISTRIP was not a POSIX invention;
it was existing practice, as was the entire 8-bit byte orientation of
the terminal device support (parity bits etc.)  If you need all 8 data
bits for your terminal connection then simply don't specify ISTRIP to
the terminal handler.  Unlike V7/BSD tty handlers that discard input
when switching canonicalization modes, the 1003.1 model (like UNIX
System V) doesn't demand such input flushing, making it suited just
fine to a multibyte environment.  Keep in mind that multibyte characters
are required by higher-level standards and conventions to be provided
as byte streams, not single-text-character-representation chunks.  There
could obviously be surprising effects when, for example, the user is
trying to "erase" a just-typed text-character, not just the final byte
of it, if the terminal handler does not understand the intention of the
"erase" function, but that need to be dealt with at a lower level than
the application/OS interface that 1003.1 specifies.

The 1003.1 terminal control functions are simply an interface to the
underlying primitive operations provided by existing or future
implementations, primarily those from UNIX System V augmented somewhat
by support for BSD tty features.  The original draft 1003.1 had
specified these as ioctl()s along the lines of existing practice,
slanted toward the System V specifics with a few tweaks to accommodate
BSD extensions (as opposed to being based on the V7/BSD tty ioctl()s).
While that was the right blend of functionality, there were two main
objections.  (1) It meant either wedging a separate-but-equal tty
interface into the OS "kernel", which is effectively what a later
release of BSD went ahead and did, or else "layering" an emulation of
the POSIX ioctl() behavior around an existing but different tty ioctl(),
along the lines of the BRL UNIX System V emulation for 4BSD.  People
weren't terribly happy with either option.  (2) Handling terminal
behavior via bit vectors and ioctl()s is awkward and error-prone; few
applications I have seen get this entirely right.  Interfaces to allow
the programmer to more directly and cleanly specify the desired actions
are clearly needed, and since they didn't exist as part of existing
commercial UNIX systems (every application programmer ended up rolling
his own), devising a standard interface for this widely-but-varyingly-
implemented facility was a positive service to the programmer.  There
is nothing preventing you from continuing to use your existing kludges
instead of the POSIX standard terminal control interface, but as a
matter of improved portability you should probably change your local
kludges to match the POSIX interface and use the vendor-provided
version when it exists instead of replacing it with yours.  In the
long run that should mean that you can stop having to deal with tty
variations when porting software.

In summary, I think 1003.1 addressed the terminal control functionality
sensibly and responsibly, and that there is no need for it to address
the kinds of things that you seem to be talking about.


Volume-Number: Volume 26, Number 20