Misfunctionality? OpenBSD's sleep(1)

[Ville <viha@vip.fi>]

#include <std_disclaimer.h>

/* Inserts random excuses if this misfunctionality is already known and
   is in fact not a bug. And, yes, this must have been fixed eons ago
   and I failed to read the proper ChangeLog and what not...            */


Hi.

I recently experimented with OpenBSD's sleep(1) and sleep(3). I don't
normally do any development on it, so... Don't be surprised if I got
homework left to do. *sigh*

Considering the trivial nature of this misfunctionality, I would dare
to suspect it is already known (even if not publically), but here goes-

	~> time sleep 4
	<snip> 0:03.99 <snap>

	But-

	~> time sleep 100000001
	<snip> 0:00.00 <snap>

	...Whereas '100000000' (== the number -1) would seem to perform
	the way it is supposed to, ie. you'll have to wait.

	As if this wasn't already confusing enough, sleep(1) on OpenBSD
	comes up with:

	~> sleep 100000001 && echo Succesful.
	Succesful.

	The man-page (1) claims '>0    An error occurred.' ?

	ie. The program does not signal it did not in fact wait for the
	specified amount of time. Whereas on FreeBSD/Linux even the command
	"sleep `perl -e 'print "9" x 1024'`" hangs (ie. waits) and is as
	such more logical.

	A few OSes I tried, on the other hand, have a sleep(1) that does
	the job but a sleep(3) that corresponds to the one on OpenBSD
	(=<100M).

	Some CGIs may offer the user the ability to choose the time for
	which a certain task/game should run et cetera. And as 'sleep'
	behaves in this differing fashion on OpenBSD, other processes
	relying on it may (if people are extremely lucky) provide useful
	conditions for outsiders trying to gain access. This is often
	the case when the program being ran was only tested on Linux or
	FreeBSD.

	Also, if a program is dumb enough to constantly multiply the guess
	delay (ie. a program requiring authentication) with a big number,
	the result is that [too] diligent hackers will become delay-free
	after a dozen attempts (which may well take half a year or even
	more, but hey, it's good to be complete for the sake of paranoia).

	sleep(3) naturally gives no warnings when compiling, but does
	return 4 as an error value which helps out the programs that do
	perform the appropriate checks. man nanosleep/usleep could have
	been the key (some maximum values are mentioned there), but I
	didn't pay too much attention checking if they are directly the
	ones used here ....  At least the question 'How many really go
	that far with a function/command as simple as this one?' remains
	unanswered.

	The workaround (as if I should need to say it aloud) is to divide
	the sleep up as necessary. This can be easily achieved with say
	'while' and a few lines of code.

Thoughts?


-- 
Ta ta & Happy Holidays,

	- Ville/viha@cryptlink.net (Cryptlink Networking)