home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / unix / 505 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  4.3 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: stephe@mks.com (Stephen Walli)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
  5. Date: 30 Dec 1992 14:55:35 -0800
  6. Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
  7. Lines: 76
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1ht9d7INNfpf@ftp.UU.NET>
  11. References: <1halvbINN9kd@ftp.UU.NET> <1hbkbtINNmh8@ftp.UU.NET> <1hdndfINNi52@ftp.UU.NET> <1hg6ucINNft5@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: stephe@mks.com (Stephen Walli)
  16.  
  17. In <1hg6ucINNft5@ftp.UU.NET> karish@pangea.Stanford.EDU (Chuck Karish) writes:
  18.  
  19. Thank you for taking the time to comment, but I believe I disagree with 
  20. your comments. 
  21.  
  22. >In article <1hdndfINNi52@ftp.UU.NET> stephe@mks.com (Stephen Walli) writes:
  23. >>To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
  24. >>done. It will go in front of the IEEE Standards Board in June. There are no
  25. >>test methods. 
  26. >>....
  27. >Remember that a lot of the functionality in POSIX.4 is invented,
  28. >either extending what's in existing implementations or specifying
  29. >the behavior differently.
  30. >It will be even more important for this standard than for POSIX.1
  31. >and POSIX.2 to have agreed-upon test methods.
  32.  
  33. Why? I fail to see the connection between the above two paragraphs.  If
  34. a lot of POSIX.4 *is* invented, then I would be *real* scared of
  35. trusting them to get the test method specification correct without the
  36. benefit of real implementations of the base standard upon which to cut
  37. real test suites. I would hope that large procurement groups such as
  38. the U.S. government would never choose so naive a specification for
  39. testing for a possible FIPS of POSIX.4.
  40.  
  41. >The fact that the IEEE Standards Board won't publish the standard yet
  42. >does nothing to prevent OS vendors from implementing the C binding,
  43. >and thus has little effect on the individual programmer's ability to
  44. >use its features.  
  45.  
  46. I disagree. VMS implemented to POSIX.4/Draft 9. QNX has implemented a
  47. few chapters out of Draft 9 as well, (I think.) I'm not sure how
  48. current Lynx is. There is at least one other vendor I know of,
  49. implementing to Draft 10. The sooner the working group's work is done,
  50. the sooner the IEEE Standards Board can approve it, and the sooner the
  51. IEEE can publish it.  Until then, there is no definitive reference for
  52. a programmer to follow or brow beat a vendor.
  53.  
  54. >The tradeoff, from the programmer's point of view,
  55. >is that the sooner test methods are agreed upon, the sooner it will
  56. >be possible to write portable code that can be expected to work on
  57. >all POSIX.4 systems that support the applicable option(s).  
  58.  
  59. Again I ask, why?  The sooner the POSIX.4 *standard* exists, the sooner
  60. a programmer can write portable code. Test methods *standards* do not
  61. matter.  The only organizations that seem to really care about test
  62. methods *standards* are large governmental procurement agencies.
  63. Testing is expensive. They don't have the money to develop the suites
  64. in house anymore, in these recessionary times.
  65.  
  66. There is nothing preventing them when they are evaluating possible
  67. suites to test conformance to a standard, from laying down the criteria
  68. that the suites document individual test cases according to the grammar
  69. laid out in POSIX.3 (Test Methodologies for POSIX Standards), and that
  70. they report status accordingly.  This would give them a basis for
  71. judging test suites, one against the other.  They could even request
  72. that individual test cases are tagged with some sort of
  73. Section.subsection.page.line# identifier, and the quoted text from the
  74. base standard, so someone could go through the standard with a
  75. high-liter, (crude as this may seem,) to check for coverage.  They will
  76. likely get a better suite, if they have more than one real suite to
  77. judge against, than by asking the standards working groups to second
  78. guess what a test suite will look like. Or they can pay the testing
  79. houses like Mindcraft, Unisoft, Datafocus, and Perennial to develop the
  80. suites in this manner. This is not work that should be hoisted onto the
  81. standards development working groups any longer.
  82.  
  83. cheers,
  84. stephe
  85. -- 
  86. Stephen R. Walli,       stephe@mks.com | Just say ``NO'' to anticipatory 
  87. Mortice Kern Systems Inc.              | standards. 
  88. phone: +1 (519) 884-2251               |
  89.  
  90. Volume-Number: Volume 30, Number 15
  91.