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

Text File | 1992-02-21 | 5.6 KB | 107 lines

Submitted-by: [e-mail] (John F Haugh II)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>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.

I'll start with just my remarks regarding ISTRIP since they seem to have
generated the most heat.

It was not my intention to claim that POSIX invented ISTRIP, indeed,
they did not - it's mentioned in my System V manual which predates the
notion of POSIX by several years.  Rather, it is my claim that ISTRIP
is required to be supported and that if you support it as described
by the standard, then 8 bit code sets will be destructively translated
on input.  Furthermore, the recovery from such an event is non-trivial
(that is, you can't just turn parity on for your TTY device and make
it work correctly.) for the end user.

As an example, EBCDIC has its characters spread throughout the entire
8 bit range.  If ISTRIP should become turned on, the translation
of the EBCDIC character 'a' would be from 0x81 to 0x01, and for 'A'
it would be from 0xC1 to 0x41.  While the response is often "Don't
do that then", the complaint which I have is that POSIX could have
had the foresight to 1) not require ISTRIP be supported for all
asynchronous hardware interfaces (that is, it becomes implementation
defined as to being supported or not) 2) defined it in terms of the
size of the character being received (that is, "cs7" would mean
"strip to 7 bits" and "cs8" would mean "strip to 8 bits") or 3)
something completely different.  I tend to prefer 1) since 7.1.2.4
defines parity, and it seems ISTRIP is really a parity and word-size
issue.

Both the Rationale and 7.1.2.2 explicitly refer to 7 bit characters
"which are common".  Anyone who has worked with characters from the
international character sets is aware that outside of these United
States, 8 bit characters "are common".  There is no room to change
ISTRIP to be more meaningful in the environment which it exists in
because the standard has explicitly stated that it must exist, and
that it must behave in a specific fashion.

>                                            (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.

This touches on part of my complaint.  By specifying ISTRIP in the
manner which it has been described, a portable application can never
use it since that application is never assured of knowing the size
of its input characters (that is, 7 bits or 8).  It really is an
implementation defined function that the implementation should have
been allowed to control more to its liking.  If, as the Rationale
says "Although the ISTRIP flag is normally superfluous in today's
terminal hardware and software", why is it a required feature?  As
an example of where POSIX is more to my liking, 7.1.2.4 allows the
implementor the decency of not supporting 5, 6, or 7 bit characters
where the underlying hardware may not support such (or even where
it just may not make sense).

>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.

Perhaps from a US-centric perspective there isn't - 7 bit ASCII is
the predominant code set, but as POSIX-like operating systems make
their way to Europe and beyond, this conflict between 7 bit and
8 bit code sets will become more evident.

The question which needed to be asked is "What happens if I take
an 8 bit character and process it with a POSIX compliant terminal
interface?"  Which brings up my question, given that ISTRIP must
behave according to the specification, how can I support it in an
environment where 8 bit characters are common?  The answer is I
can't and it is completely meaningless to do so - and there, but
for the grace of POSIX go I ...

I can appreciate the statement that the programmer should only
change those bits which are relevant or needed, but as Doug states
above, controlling terminal modes with a collection of bit vectors
is prone to error.  The end user will not care where the problem
lies, only that there is one.  I think that Vince Lombardi said
"By failing to prepare, you are preparing to fail."  This sums it
up - there is no graceful path for non-7-bit character sets to
be supported via that is not "error-prone".
--
John F. Haugh II        |I am the NRA.     | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] |Take a friend shooting.| Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik


Volume-Number: Volume 26, Number 22