home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / unix / 507 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  2.4 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: preece@urbana.mcd.mot.com (Scott E. Preece)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
  5. Date: 4 Jan 1993 16:29:05 -0800
  6. Organization: Motorola MCG, Urbana Design Center
  7. Lines: 39
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1iakohINNbpe@ftp.UU.NET>
  11. References: <1halvbINN9kd@ftp.UU.NET> <1hbkbtINNmh8@ftp.UU.NET> <1hdndfINNi52@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
  16.  
  17. The problem is that in the current environment saying "Don't make us
  18. write test methods" really means "We think it's better to send the
  19. standard our a little half-baked than to take the time to remove another
  20. round of ambiguities."  That *may* be the right answer.  It may very
  21. well be that more ambiguities will be exposed and interpreted by getting
  22. the standard out for people to implement.  On the other hand, it also
  23. may be that each implementor will guess and interpret when faced with
  24. ambiguity, rather than seeking interpretation through inconvenient and
  25. possibly slow official channels.
  26.  
  27. What is important about the test method requirement is that it requires
  28. the standard writers to translate the specification into another form.
  29. There is no structural guarantee that the alternative form will be
  30. complete or perfect, but there is a high probability that *some*
  31. ambiguities will be exposed.
  32.  
  33. My experience with trying to get a system to meet a standard that was
  34. intended to be quite unambiguous (the 88000 version of the SVR4 ABI) is
  35. that none of the existing standards is there yet and that forcing the
  36. authors to think about them a little longer and in a different form is
  37. for the good, though I must also acknowledge that I don't know how my
  38. own work group is going to get that work done, either.
  39.  
  40. If we can't keep our people and our companies interested, we're going to
  41. be stuck with one unambiguous standard: what runs successfully on NT on
  42. the architecture whose name I prefer to leave unuttered...  I think that
  43. would be for the worse, and I hope I would feel that way even if it were
  44. our architecture that were the common reference.
  45.  
  46. --
  47. scott preece
  48. motorola/mcg urbana design center    1101 e. university, urbana, il   61801
  49. uucp:    uunet!uiucuxc!udc!preece,     arpa:    preece@urbana.mcd.mot.com
  50. phone:    217-384-8589              fax:    217-384-8550
  51.  
  52.  
  53. Volume-Number: Volume 30, Number 17
  54.