It's still 32 bit. Signed-off-by: Eugene Syromyatnikov <evgsyr@xxxxxxxxx> --- man2/getrlimit.2 | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/man2/getrlimit.2 b/man2/getrlimit.2 index 3a4d48f..b0adfb2 100644 --- a/man2/getrlimit.2 +++ b/man2/getrlimit.2 @@ -762,7 +762,11 @@ and .BR setrlimit () system calls is a (32-bit) .IR "unsigned long" . -Furthermore, in Linux versions before 2.6.36, +.\" Linux still uses long for limits internally: +.\" c022a0acad534fd5f5d5f17280f6d4d135e74e81 +.\" kernel/sys.c:do_prlimit() still uses struct rlimit which +.\" uses kernel_ulong_t for its members, i.e. 32-bit on 32-bit kernel. +Furthermore, in Linux, the kernel represents resource limits on 32-bit platforms as .IR "unsigned long" . However, a 32-bit data type is not wide enough. @@ -788,15 +792,6 @@ wrapper function silently converted the limit value to .BR RLIM_INFINITY . In other words, the requested resource limit setting was silently ignored. .PP -This problem was addressed in Linux 2.6.36 with two principal changes: -.IP * 3 -the addition of a new kernel representation of resource limits that -uses 64 bits, even on 32-bit platforms; -.IP * -the addition of the -.BR prlimit () -system call, which employs 64-bit values for its resource limit arguments. -.PP Since version 2.13, .\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201 glibc works around the limitations of the -- 2.1.4
