tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: alarm(3) bug?

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)

Home | Main Index | Thread Index | Old Index