home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0022.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  2.8 KB  |  57 lines
  1. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  2.  
  3. >Submitted-by: jfh@rpp386.cactus.org (John F Haugh II)
  4. >... Which brings up my question, given that ISTRIP must
  5. >behave according to the specification, how can I support it in an
  6. >environment where 8 bit characters are common?  The answer is I
  7. >can't and it is completely meaningless to do so ...
  8.  
  9. Certainly you can support it, in the same way that most Unix systems
  10. support delay options for Teletype Model 37 printing terminals even
  11. though no Model 37s are in use with those systems or ever will be.
  12. It may be useless in your environment, but you can always continue
  13. to support it.
  14.  
  15. >I can appreciate the statement that the programmer should only
  16. >change those bits which are relevant or needed, but as Doug states
  17. >above, controlling terminal modes with a collection of bit vectors
  18. >is prone to error.  The end user will not care where the problem
  19. >lies, only that there is one.
  20.  
  21. If ISTRIP was the only bit that could foul up user terminal input, this
  22. might be a telling argument.  It's not, so this is a ridiculous argument.
  23. Changing random bits in the terminal mode is *almost guaranteed* to cause
  24. trouble.  Eliminating ISTRIP would not change that.
  25.  
  26. >... If, as the Rationale
  27. >says "Although the ISTRIP flag is normally superfluous in today's
  28. >terminal hardware and software", why is it a required feature? ...
  29.  
  30. Read the rest of the paragraph containing that phrase.  "...it is
  31. historically supported.  Therefore, applications may be using ISTRIP,
  32. and there is no technical problem with supporting this flag.  Also,
  33. applications may wish to receive only 7-bit input bytes and may not
  34. be connected directly to the hardware terminal device (for example,
  35. when a connection traverses a network)...  Also, there is no requirement
  36. in general that the terminal device ensures that high-order bits beyond
  37. the specified character size are cleared.  ISTRIP provides this function
  38. for 7-bit characters..."
  39.  
  40. In other words, it does have potential uses for applications that really
  41. do want to see only 7-bit input.  Those applications arguably are broken
  42. and need fixing, but supporting them -- while the customers are still
  43. buying and using them -- is trivial.  Standards are not in the business of
  44. legislating morality; their job is to recognize reality.  If the customers
  45. rise up and insist that those applications be fixed -- a development that
  46. most of us would cheer -- then ISTRIP will fall out of use and eventually
  47. can be removed from the standard.  While it remains in use, it is plausible
  48. to include it in the standard, given that it is easy to support (which it
  49. is, since it's about two lines of code in the terminal driver).
  50. -- 
  51. SVR4:  the first system so open that    | Henry Spencer @ U of Toronto Zoology
  52. everyone dumps their garbage there.     |  henry@zoo.toronto.edu  utzoo!henry
  53.  
  54.  
  55. Volume-Number: Volume 26, Number 23
  56.  
  57.