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