home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 421 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  3.7 KB

  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: henry@zoo.toronto.edu (Henry Spencer)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Report on POSIX.2: Shell and Utilities
  5. Date: 12 Sep 1992 17:38:29 -0700
  6. Organization: U of Toronto Zoology
  7. Lines: 61
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <18u2i5INNo7e@ftp.UU.NET>
  11. References: <18lqglINN992@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  16.  
  17. >Submitted-by: pc@hillside.co.uk (Peter Collinson)
  18. >September the 16th, 1992... the IEEE Standards Board is due to approve P1003.2
  19. >as an IEEE Full Use Standard...
  20.  
  21. Which is a pity, unfortunately, because despite all the delays, if ever a
  22. standard deserved to spend some time at the intermediate stage of Trial
  23. Use Standard, it's this one...
  24.  
  25. The fundamental problem is that most of 1003.2 has never been implemented
  26. *from scratch* by people working only from the spec.  The folks who claim
  27. to have implemented it have been hacking existing implementations to fix
  28. what they think are the differences between their code and the standard.
  29. They've missed all the interesting little places where the behavior called
  30. for by 1003.2 is subtly different from what the existing code does, or
  31. isn't even sufficiently well-defined to determine whether the existing
  32. code meets it.
  33.  
  34. I've been only lightly involved with 1003.2, but in the three areas where
  35. I have paid careful attention -- regular expressions, awk, and grep -- we
  36. *know* there are still bugs in 1003.2.  Not big ones, but not entirely
  37. trivial either.  The scary part is that both 1003.2 regular expressions
  38. and 1003.2 awk were considerably improved at the eleventh hour because I
  39. actually *tried* from-scratch implementations (although only a partial
  40. one in the case of awk), and the lengthy 1003.2-bug lists that resulted
  41. arrived (just) in time to get things fixed.  Unfortunately, I and others
  42. have found more since, and it's too late.
  43.  
  44. Understand:  this is not the result of gross negligence.  I reviewed several
  45. of the earlier regular-expression drafts; I *thought* they looked fine.  As
  46. did other competent people.  Similarly, the awk draft looked fine to me --
  47. and to people who have implemented awk -- until I actually tried to write
  48. a parser from it, at which point I noticed that (for example) nobody had
  49. ever specified the precedence of the "|" operator...
  50.  
  51. It's too late to do anything about 1003.2, I'm afraid, except to push for
  52. a revised version soon (but not instantly -- we desperately need some more
  53. implementation experience first), and meanwhile be aware that the standard
  54. is seriously flawed and *is* likely to get revised.  But I'm deeply
  55. concerned about the wider implications.  There isn't much wrong with
  56. 1003.1, but it sure looks to me like that happy state of affairs isn't
  57. going to be repeated for the later POSIX standards, especially the big
  58. and complex ones like 1003.2.
  59.  
  60. What can be done?  Just getting more people involved is *not* the answer,
  61. although it can't hurt and might help a little.  In the three areas I
  62. mentioned above, the specs were already being reviewed by some of the
  63. Unix community's top experts in the topics, including major implementors.
  64. You just canNOT find these problems without writing code from the spec.
  65. Nothing else works.  We need to find some way to encourage more early
  66. implementations (from scratch, not as modifications of existing ones,
  67. so the specification problems get faced squarely), and preferably some
  68. way to keep the standards from getting cast in concrete until at least
  69. the early returns are in.
  70. -- 
  71. There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
  72. mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
  73.  
  74.  
  75. Volume-Number: Volume 29, Number 33
  76.