[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
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
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?
--apb (Alan Barrett)
Main Index |
Thread Index |