🚀 go-pugleaf

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