Bug report

Bug description:

• as per System Calls Manual (man 2 setrlimit),rlim_t is anunsigned 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")

returns18446744073709551614

• executingulimit -t 18446744073709551614, then in python3resource.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)).valuerlimit= (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