std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/26/86)
[ This is being crossposted to several newsgroups by request.
Followups should be to mod.std.unix, i.e., mailed to ut-sally!std-unix,
or sent as mail replies to Donn Terry at hplabs!hpfcla!donn or
the paper mail address below. -mod ]
From: utah-cs!hplabs!hpfcla!hpfcdc!donn (Donn Terry)
Date: Mon, 20 Oct 86 16:54:44 mdt
WeirdNIX
... or destructive QA of a standard.
The IEEE P1003 committee is offering prizes for the the best new and
technically legal interpretation of the POSIX(*) standard which
nevertheless violates the intuitive intent of the POSIX standard.
The intent is to find how the standard might be misinterpreted, and then
to correct the errors that the misinterpretations point out. Like
destructive testing of hardware, you stress it until it breaks and then
fix what broke so you can then stress it further.
The criteria for judging the misinterpretations are:
It must be an interpretation of the P1003.1 POSIX Trial Use standard (as
published by IEEE) which conforms completely to the standard. For the
purposes of the contest, Appendices C.5, E.1 and J are included as part
of the standard, but no other Appendices.
It must be represented as a detailed description in either pseudo-code
and or text as how an implementation could behave so as to conform with
the standard and still do "the wrong thing". Annotation as to why the
interpretation is considered legal by the submitter will be of
significant value in judging.
Interpretations must be of topics discussed in the standard. Areas that
are not covered by the standard are not eligable. Interpretations which
use some features of the standard and then take advantage of something upon
which the standard is silent (and thus should not be) will be of significant
value.
If there are similar entries, postmark dates will be used. If the entry
is submitted electronically, the postmark date will be the time and date
of mailing. In case of a tie, the entry with the earliest postmark will
be used.
The winners will be judged by a subset of the IEEE P1003 working group,
and the members of that group are not eligable for prizes. Members of
the working group for the purposes of this contest are those individuals
who attended either 2 or more of the most recent 4 working group meetings,
or who attended in Palo Alto. The decision of the judges is final.
Prizes will be awarded to the "best" and "most demented" interpretations.
"Best" is an interpretation that is legal and which is "likely", in that
one could reasonably make the mistake and implement a system which did
that. "Most demented" is a legal interpretation that would not actually
be implemented because it violates common sense.
More than one first prize in each category may be awarded if, in the
interpretation of the judges, the best submittals are of comparable quality
and are distinct problems. Zero or more second prizes may also be awarded.
The first prize consists of:
+ Hewlett-Packard has agreed to donate some HP 16C calculators.
+ having your name in a place of honor in the acknowledgements
section of the P1003.1 final use standard,
+ a copy of the final use standard (with your name in it!)
Second prizes (if any) consist of:
+ special mention in the acknowledgements section of the P1003.1
final use standard,
+ a copy of the final use standard (with your name in it!)
The winners will be announced at USENIX/UniForum in January. Deadline for
arrival of paper submittals is Friday, December 8th. Submittals arriving
after that date will be considered only if they are in electronic form so
they can be judged remotely. No submittals will be considered after
January 1, 1986. Submittals should be sent either by mail (before
December 8th) or by electronic mail to:
Donn Terry
co-Chair P1003.1
Hewlett-Packard Co.
3404 E. Harmony Rd.
Ft. Collins, Co. 80525
{hplabs!}hpfcla!donn
The submitters of all interpretations that are considered for prizes
(first postmark and legal) will be listed as contributors to the standard.
Submitting a proposal to the contest releases it to be used by IEEE both
to improve the standard, and to publish it as it sees fit.
A sample submittal follows (with thanks to Hal Jespersen). The exact
form is not critical, but this submittal, were it eligable, would definitely
get consideration for a prize. (In any case, it will be fixed!)
Problem:
getcwd() can legally return "."
Explanation:
getcwd() returns a pointer to the pathname of the
current working directory. The definition of
pathname allows the dot directory as a valid
pathname. Returning dot from getcwd() is an
effective no-op, but legal.
Proposed Correction (optional):
Add the following as a second sentence in sect 5.2.2.2:
"The pathname that is pointed to is a full pathname,
expressed relative to the root directory."
Donn Terry
Volume-Number: Volume 7, Number 87std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/26/86)
[ This is crossposted to several newsgroups by requests (it's a followup to a similar article). Further followups should go to mod.std.unix, i.e., be mailed to ut-sally!std-unix. Replies should go to Donn Terry. -mod.std.unix moderator ] From: utah-cs!hplabs!hpfcla!hpfcdc!donn (Donn Terry) Date: Mon, 20 Oct 86 16:54:44 mdt The schedule on this is a little tighter than I'd like it to be, but after getting all the approvals, it only leaves about 1.5 months to run the contest if we close things off in time to judge at the December P1003 meeting. Thus the fact that electronic topics will be accepted later. We can continue the judging via mail afterwards, if there is stuff to judge. If the people who had the original idea (who may wish to remain anonymous) want credit, let me know. This idea is sufficiently "unusual" that they may not want to take the blame#####credit :-) . Please pass this on to your friends. The more submittals, the better. Donn Terry Volume-Number: Volume 7, Number 88
donn@hpfcdc.uucp (Donn Terry) (02/04/87)
[ The results of the Weirdnix contest (to find legal misinterpretations
of the POSIX Trial Use Standard) were announced at the USENIX Conference
a couple of weeks ago in Washington, D.C., by me and Jim McGinness.
Unfortunately, we did not have the full text of the winning entries
at the time. However, I promised to post them here. Donn Terry,
the P1003 co-chair and an originator of the contest, has supplied
them in this posting. -mod ]
The Weirdnix winners' proposals appear below.
The winner in the most serious category was Paul Gootherts of HP.
Problem:
The definition of sleep() is inconsistent.
Explanation:
"The value returned by the sleep() function shall be the unslept
amount (the requested time minus the time actually slept)."
[Para 3.4.3.3]
"The suspension time may be longer than requested by an
arbitrary amount due to the scheduling of other activity in the
system."
[Para 3.4.3.2]
Since the time actually slept can be greater than the time
requested, the value returned could be negative. However,
sleep() returns an unsigned int.
[Para 3.4.3.1]
Proposal:
Sleep() could be changed to return a signed int. This is nice
because the process that called it could get some idea of how
"late" the alarm came.
Alternatively, the routine could be documented to return zero if
the actual time was greater than the requested time.
Paul Gootherts
Hewlett Packard, ITG/ISO/HP-UX, hpda!pdg
------------------------------------------------------------------------
In the most demented category:
>From Michael Gersten. (michael@stb from what I can determine from the
mixed address I have; as I write this I havn't succeeded in contacting
him yet.) (Michael: please write me at hplabs!hpfcla!donn.)
Ok, let's look at read() and write().
1. There is no requirement that anything written will be available for a
read().
2. There is no requirement that read/write return everything that they can.
In general, you can't require this. The terminal lines are a good example;
writing to a terminal will not result in it being readable; the terminal
drivers only return a line at a time no matter how much is requested. Or
at least, that's what the docs say (I've never actually tested it, but it
seems that if it were false, then type-ahead would not work as well.)
In general, it is probably safe to require that anything written to a file
should be available to a subsequent read provided that the read is done on
a file descriptor corresponding to the same name, or a link to the same
named file that was written to, all providing that it is a regular file.
Certainly not for device or special files.
Incidently, don't think that 2 is obvious; my first unix programs assumed
that the O/S would return a number of bytes so that the reads would be
re-aligned on a 512 byte boundary, and that I had to call read() multiple
times until I had gotten everything. I was quite suprised to find that
other people had written stuff that did not do this, and even more
suprised to find that it actually worked. No :-)
Michael Gersten
Volume-Number: Volume 9, Number 48