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

Text File | 1992-02-21 | 3.5 KB | 67 lines

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>No, read what I said again.

I did read it again - and the question remains, what if I do (for some
God awful reason) specify ISTRIP to my terminal handler?  In an
environment where that can't POSSIBLY be a useful action, how should
the system react?

>How?  I assure you that ISTRIP (or its equivalent) is not getting
>mysteriously turned on on any of the systems I use; my terminal uses
>an 8-bit binary packet protocol and I have never seen it broken by a
>sudden shift into ISTRIP mode.  If your system has such a bad bug,
>you should get the bug fixed rather than rail against the availability
>of an often-useful feature.

This has nothing to do with SYSTEM supplied software.  I can control
the system software to never ever turn that feature on - that's the
easy part.  The hard part is doing the same for the end user.  My
claim (read this real carefully) is that the USER is being given a
means of shooting themselves in the foot which serves no useful
purpose.  For a system which requires 8-bit data, ISTRIP is never
an "often-useful feature".  It is a completely meaningless and
destructive data transformation.  It isn't benign like XTABS, or
XCASE or even the Model 37 carriage delays (which are completely
harmless to all but the impatient).  Transforming 0x81 to 0x01 is
WRONG and can't be made "right" somehow.  If you wish to reply,
please address that point.

>Basically, it was one of numerous tty handler capabilities provided by
>the standard implementation on which the 1003.1 specification was based;
>there are several of these (ioctl bits) that aren't widely useful; if
>they don't meet your needs then you should feel free to not use them.
>Generally, the interface bit rate, framing, parity, etc. should not be
>altered by applications; they should be left exactly as established by
>the system agent that established the tty port connection.

And what do you do when they DO somehow get changed?  The standard
says I am free to ignore speed, character size and parity changes
if the hardware doesn't support them.  ISTRIP, which is really a
function best described in terms of character size and parity bits,
doesn't fall under this same privision.  It is completely obvious
to me that the SYSTEM shouldn't contain any of these mistakes, but
I want to know what leaway POSIX left to insure the USER doesn't
commit the same blunder.  Setting an 8-bit interface to 5 bits has
as escape route - ignore the change.  Same for parity changes and
baud rate.  The $64M question is, why not ISTRIP?

You are reading this as though I am the programmer, not the implementor
and as though the programmer (my customer) is going to smile after
pointing a gun at his foot, pulling the trigger, and discovering the
hole that I warned him about.  My intention is that you view this as
a "Quality of Implementation" sort of issue - consider if the "privilege"
required by link() for directories is "the Earth is still spinning on
its axis".  How much sympathy would a user who creates a directory mess
have for you, the implementor, after being bitten by this "feature"?
Would you buy a POSIX-compliant system which behaved this way?
--
John F. Haugh II        | Every 56 days.   | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] | Give Blood, often.    | Domain: [e-mail]
" ... expectation is the mother of disappointment."
        -- Brad Konopik

Volume-Number: Volume 26, Number 31