At Fri, 24 Dec 2004 09:42:30 +0000,
Gerrit Pape wrote:
>
> On Fri, Dec 24, 2004 at 04:51:30PM +0900, GOTO Masanori wrote:
> > At Wed, 22 Dec 2004 14:12:04 +0000,
> > Gerrit Pape wrote:
> > > Hi, according to the man page and
> > > http://www.opengroup.org/onlinepubs/009695399/functions/nice.html
> > > nice() should set errno=EPERM in case the incr argument is negative and
> > > the calling process does not have appropriate privileges.
>
> > It's like old BSD vs SysV question. This behavior written in SUS is
> > SysV derived. However, BSD returns EACCES like glibc. Look at info
> > libc, it describes as follows:
> >
> > - Function: int nice (int INCREMENT)
> > Increment the nice value of the calling process by INCREMENT. The
> > return value is the new nice value on success, and `-1' on
> > failure. In the case of failure, `errno' will be set to the same
> > values as for `setpriority'.
>
> I stumbled across this because the diet libc and also the uclibc use the
> Linux kernel's implementation (on most archs) which sets errno=EPERM
Indeed. Almost architecture defines __ARCH_WANT_SYS_NICE, but some
architectures do not assign even system call number.
> The dietlibc showed different behavior on ia64 where __NR_nice is not
> defined; I fixed this for consistency
>
> #ifndef __NR_nice
> int nice(int i) {
> if (setpriority(PRIO_PROCESS,0,getpriority(PRIO_PROCESS,0)+i) == -1) {
> errno=EPERM;
> return -1;
> }
> return getpriority(PRIO_PROCESS,0);
> }
> #endif
>
> It bothered me that glibc's implementation and the Linux kernel's
> disagree.
>
> > I'll close this report unless you have other opinion.
>
> Fine with me, it would be nice to have consistent behavior of the kernel
> and the different libcs in Debian though.
One idea is we could switch this behavior with __USE_UNIX98 compile
option. Though I feel it's excess to introduce such modification.
Thinking about nice(2) vs getpriority(2), I think the current glibc
hehavior is natural than SUS definition. Listening to the opinion
from upstream glibc team or kernel guys or austin group people would
be nice.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
