Re: alarm(3) bug?

[Alan Barrett <apb%cequrux.com@localhost>]

On Wed, 24 Oct 2012, James K. Lowden wrote:
> 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.

I can't see a way for NetBSD's kernel setitimer to fail, given the 
way it is called by alarm(3) in NetSBD's libc, but I could have 
missed something.

> 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.

No matter how much validation you do in libc, you need to (a) do 
something if your validation fails, and (b) call the kernel if 
your validation was successful.  The kernel syscall should never 
fail, especially if you validated the input, so in the common case 
you will then (c) return the correct result; but if the kernel 
does report an error then (d) you need to do something.  So there 
are two possible error cases (a and d), and one possible success 
case (c).  POSIX might deny that (a) and (d) can happen, but in 
reality we need to return some result if they do happen.

I think there were implied questions behind some of the other 
comments, so let me try to make some of them explicit:

What advantage do POSIX semantics have over NetBSD semantics?

How could a reasonable program, expecting POSIX semantics and 
passing reasonable values to alarm(), ever tell the difference?

Is the glibc approach of having alarm() return 0 after the kernel 
reports an error really better than the NetBSD approach of having 
alarm() return (unsigned int)-1 after the kernel reports an error? 
Why?

--apb (Alan Barrett)