resource library (getrlimit, setrlimit) interprets resource limits as signed integers instead of unsigned

[ArturBieniek4]

Bug report

Bug description:

• as per System Calls Manual (man 2 setrlimit), rlim_t is an unsigned integer type
• in Python, reading the default hard limit (resource.getrlimit(resource.RLIMIT_CPU)) will return -1
• executing this:

resource.setrlimit(resource.RLIMIT_CPU, (-2, -2))
os.system("ulimit -t")

returns 18446744073709551614

• executing ulimit -t 18446744073709551614, then in python3 resource.getrlimit(resource.RLIMIT_CPU), will return -2

This behaviour is very weird and will cause the following rather useful and common snippet to fail:

_, hardlimit = resource.getrlimit(resource.RLIMIT_CPU)
rlimit = (min(timelimit, hardlimit), hardlimit)
resource.setrlimit(resource.RLIMIT_CPU, rlimit)

There happens to exist the following workaround:

_, hardlimit = resource.getrlimit(resource.RLIMIT_CPU)
softlimit = ctypes.c_long(min(seconds, ctypes.c_ulong(hardlimit).value)).value
rlimit = (softlimit, hardlimit)
resource.setrlimit(resource.RLIMIT_CPU, rlimit)

but it just feels extremely hacky to do things like this and I believe a lot of programmers end in this trap.
Especially that when you handle the -1 case specially (as it is mentioned in man, that "RLIM_INFINITY typically is the same as -1"), it still fails with other negative values like -2.

CPython versions tested on:

3.15

Operating systems tested on:

Linux

[serhiy-storchaka]

This is one of the cases where the integer type is unsigned, but -1 is a special value. RLIM_INFINITY is defined as ((__rlim_t) -1). It is more convenient to get/set -1 on all platforms than 0xffffffff or 0xffffffffffffffff depending on platform.

There is no standard way to handle this. We have special converters for uid_t, gid_t and dev_t. It seems that it is also needed for rlim_t.

[serhiy-storchaka]

I assigned this to myself because it requires writing non-trivial bulky code, and I've already started.