This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with VMware 2.0.4 and glibc 2.2.5


On Wed, Apr 10, 2002 at 06:49:58PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 10, 2002 at 09:41:48AM -0700, H . J . Lu wrote:
> > On Wed, Apr 10, 2002 at 09:24:58AM -0700, Ulrich Drepper wrote:
> > > On Wed, 2002-04-10 at 09:06, H . J . Lu wrote:
> > > 
> > > > It looks like glibc 2.2.5 changed the ABI for nice. Shouldn't we give
> > > > it a new version?
> > > 
> > > No, we never do this for bug fixes.  If someone depends on a bug instead
> > > of reporting it they deserve what they get.
> > > 
> > 
> > Is that what people get when they read the Linux man pages? On RedHat
> > 7.2.93 (Skipjack),
> > 
> > # man 2 nice
> > NICE(2)             Linux Programmer's Manual             NICE(2)
> > 
> > NAME
> >        nice - change process priority
> > 
> > SYNOPSIS
> >        #include <unistd.h>
> > 
> >        int nice(int inc);
> > 
> > DESCRIPTION
> >        nice  adds  inc to the nice value for the calling pid.  (A
> >        large nice value means a low priority.)  Only  the  super-
> >        user   may  specify  a  negative  increment,  or  priority
> >        increase.
> > 
> > RETURN VALUE
> >        On success, zero is returned.  On error, -1  is  returned,
> >        and errno is set appropriately.
> > 
> > 
> > It is fine to fix the bug. But in this case, this "feature" is well
> > documented. You can't fix the bug by breaking the existing binaries
> > written according to the Linux man pages.
> 
> The same man page contains also:
> 
>        Note  that  the  routine  is  documented  in SUSv2 to return the new nice value, while the Linux syscall and
>        (g)libc (earlier than glibc 2.2.4) routines return 0 on success.  The new nice value can be found using get-
>        priority(2).   Note  that an implementation in which nice returns the new nice value can legitimately return
>        -1.  To reliably detect an error, set errno to 0 before the call, and check its value when nice returns  -1.
> 
> which you apparently omitted (the man page is dated back in June 2001).
> Furthermore, as it is nice(2) not nice(3) man page, on success zero is
> really returned (that's what the kernel does).

Here is the complete nice man page from RedHat 7.1:

NICE(2)             Linux Programmer's Manual             NICE(2)

NAME
       nice - change process priority

SYNOPSIS
       #include <unistd.h>

       int nice(int inc);

DESCRIPTION
       nice  adds inc to the priority for the calling pid.  Only the supe­
       ruser may specify a negative increment, or priority increase.

       Note that internally, a higher number is a higher priority.  Do not
       confuse  this  with  the priority scheme as used by the nice inter­
       face.

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and  errno
       is set appropriately.

ERRORS
       EPERM  A  non-super  user  attempts  to  do  a priority increase, a
              numerical decrease, by supplying a negative inc.

CONFORMING TO
       SVr4, SVID EXT, AT&T, X/OPEN, BSD 4.3.   SVr4  documents  an  addi­
       tional EINVAL error code.

SEE ALSO
       nice(1), setpriority(2), fork(2), renice(8)

Linux                     March 28, 1992                  NICE(2)

BTW, there is no nice (3) even on Red Hat 7.2.93 (Skipjack).

Also, I don't believe the Linux man pages (2) describe the raw kernel
syscall interface. Glibc does many translations. You can't use the
glibc data structues with syscall ().


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]