getpriority: Only getpriority translates the priority values

The translation is needed to avoid returning a negative number from a
successful syscall, and this requirement doesn't apply to setpriority.
See the implementation of getpriority in kernel/sys.c.

Signed-off-by: Theodore Dubois <tbodt@google.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>

diff --git a/man2/getpriority.2 b/man2/getpriority.2
index 4259d5ddc1a85d3062ce28505a03ee4615b9f260..8970410053c66f0a29778df2da3985aa99559105 100644 (file)
--- a/man2/getpriority.2
+++ b/man2/getpriority.2
@@ -181,20 +181,11 @@ All BSD-like systems (SunOS 4.1.3, Ultrix 4.2,
 manner as Linux 2.6.12 and later.
 .\"
 .SS C library/kernel differences
-Within the kernel, nice values are actually represented
-using the range 40..1
-(since negative numbers are error codes) and these are the values
-employed by the
-.BR setpriority ()
-and
-.BR getpriority ()
-system calls.
-The glibc wrapper functions for these system calls handle the
-translations between the user-land and kernel representations
-of the nice value according to the formula
+The getpriority system call returns nice values translated to the range 40..1,
+since a negative return value would be interpreted as an error.
+The glibc wrapper function for getpriority translates the value back according to the formula
 .IR "unice\ =\ 20\ \-\ knice" .
-(Thus, the kernel's 40..1 range corresponds to the
-range \-20..19 as seen by user space.)
+(Thus, the 40..1 range returned by the kernel corresponds to the range \-20..19 as seen by user space.)
 .SH BUGS
 According to POSIX, the nice value is a per-process setting.
 However, under the current Linux/NPTL implementation of POSIX threads,