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

Linked PRs

• gh-137044: Support large limit values in getrlimit() and setrlimit() #137338
• [3.14] gh-137044: Support large limit values in getrlimit() and setrlimit() (GH-137338) #137506
• [3.13] gh-137044: Support large limit values in getrlimit() and setrlimit() (GH-137338) #137507
• gh-137044: Make resource.RLIM_INFINITY always positive #137511
• gh-137044: Revert "gh-137044: Make resource.RLIM_INFINITY always positive (GH-137511)" #137938
• gh-137044: Fix test_resource on 32-bit Linux #137941
• gh-137044: To weaken the statement regarding the RLIM_INFINITY value #137954