Re: alarm(3) bug?

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

enh <enh%google.com@localhost> wrote:
> >> i was trying to replace bionic's hacked alarm.c with the current
> >> NetBSD alarm.c, but noticed that you return -1 on error, unlike glibc
> >> and bionic, and apparently contrary to POSIX:
> >>
> >>   http://pubs.opengroup.org/onlinepubs/009695399/functions/alarm.html
> >>
> >> "The alarm() function is always successful, and no return value is
> >> reserved to indicate an error."
> >
> > I'd say you have a bigger problem if the system call fails.
> 
> the user-observable difference between glibc/POSIX and NetBSD is for
> alarm(0xffffffff).
> 
> > The alternative would be silently ignoring the error, which doesn't feel
> > better.

Well, we could put that under POSIXLY_CORRECT, but.. the error condition
in alarm(3) should normally never happen, since setitimer(2) system call
can fail only with EINVAL or EFAULT (and libc code is passing the input,
making sure it is valid).  If the latter happens, then something in the
system is seriously broken.  If we still consider a hypothetical failure,
then return code (unsigned)-1 at least gives the caller an opportunity to
do something about it.  The value of 0xffffffff is very unlikely to be
used in practice (in theory, it is also not portable, as POSIX already
points out), unlike 0 which has a specific meaning.

One alternative is to do what Linux does, which is wrapping the same
libc code fragment in the kernel by adding alarm() system call - that
just eliminates copyin(9).  However, I do not really think it is worth.

Do you agree?

-- 
Mindaugas