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