# 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: ``` python3 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: ``` python3 _, hardlimit = resource.getrlimit(resource.RLIMIT_CPU) rlimit = (min(timelimit, hardlimit), hardlimit) resource.setrlimit(resource.RLIMIT_CPU, rlimit) ``` There happens to exist the following workaround: ``` python3 _, 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 <!-- gh-linked-prs --> ### Linked PRs * gh-137338 * gh-137506 * gh-137507 * gh-137511 <!-- /gh-linked-prs -->