Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!gatech!ut-sally!std-unix
From: donn@hpfcdc.uucp (Donn Terry)
Newsgroups: mod.std.unix
Subject: Re:  Weirdnix
Message-ID: <7081@ut-sally.UUCP>
Date: Tue, 3-Feb-87 16:36:57 EST
Article-I.D.: ut-sally.7081
Posted: Tue Feb  3 16:36:57 1987
Date-Received: Sat, 7-Feb-87 09:37:29 EST
Sender: std-unix@ut-sally.UUCP
Reply-To: seismo!hpscda!hpccc!hpfcla!hpfcdc!donn (Donn Terry)
Lines: 76
Approved: jsq@sally.utexas.edu

[ 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