Re: alarm(3) bug?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Wed, 24 Oct 2012 09:15:50 +0200
Alan Barrett <apb%cequrux.com@localhost> wrote:

> On Tue, 23 Oct 2012, enh wrote:
> > the user-observable difference between glibc/POSIX and NetBSD is 
> > for alarm(0xffffffff).
> 
> The maximum value guaranteed by POSIX is 
> 65535 seconds (about 18 hours)
.... 
> The maximum value documented in NetBSD's alarm(3) man page 
> is 2147483647 seconds (0x7fffffff seconds, about 68 years).
> 
> NetBSD's alarm(3) will return an error code only if the underlying 
> setitimer(2) syscall fails.  That is quite unlikely, but what 
> would you suggest should be done in that case?

AFAICT, the only reason setitimer(2) can "fail" is for invalid input.
itimerfix returns EINVAL if the requested time is too small or too
big.  

Is there a fundamental reason that setitimer(2) coudn't accept an
unreasonable number seconds?  If not, the validation could be moved to
libc and another alarm implementation could support Posix semantics. 

--jkl