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

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

Submitted-by: [e-mail] (Donald Lewine)

Look, one of us is being quite dense here and I don't think it is me.
I am open to the possibility that I am grossly misunderstanding you,
but I doubt it. . .

In article <[e-mail]>, [e-mail] (John F Haugh II) writes:
|> 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?
The same way the system reacts to any stupid action.  What if (for some
God awful reason), I specify exit() where I mean printf()? Or I type
"rm" when I mean "ls"?  The result is bad, I admit it.  It is less bad
than my stomping on the gas in my car instead of the break.  They are
all errors.  The world provides for countless damage due to user
errors.  In the grand scheme of things, ISTRIP is far less dangerous
than, say, "I did not know the gun was loaded."

|>
|> >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.
As I think about, ISTRIP is one of the more benign ways to screw
up a call to tcsetattr().  There are many ways which will leave you
terminal hung in a state where there is nothing you can do (at least from
that terminal) to fix it.

|> 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.
I don't claim there is any way to make it "right."  I claim that
setting the ISTRIP bit is only one of thousands of errors a user can
make.  I also claim that it is a relatively minor error that is
fairly easy to debug.

It is no worse than the programer writing:
    ch &= 0x7f;
when he ment:
    ch &= 0xff;

It is a lot less of a problem than typing "rm" instead of "ls".  I
know of people who have done that.  I know of no one who ever turned
on ISTRIP by accident.

NOTE: Calling tcsetattr() with a bad pointer can cause much more
      grief than merely setting ISTRIP.

In short, a program can set ISTRIP by mistake and cause incorrect
operation.  This error is not on the top 100 programming errors list
and is not worth the net bandwidth we have already given it!

--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]

Volume-Number: Volume 26, Number 37