classification
Title: resource max value represented as signed when should be unsigned
Type: behavior Stage: patch review
Components: Extension Modules Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ajaksu2, giampaolo.rodola, loewis, martin.panter, mdr0, nnorwitz, r.david.murray, sable, wiggin15
Priority: normal Keywords: patch

Created on 2010-09-22 01:42 by r.david.murray, last changed 2019-02-24 22:13 by BreamoreBoy.

Files
File name Uploaded Description Edit
issue9917.diff wiggin15, 2015-09-28 21:53 review
Messages (6)
msg117123 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-22 01:42
Breaking out the library bug discussed in issue 678264 from the test bug the issue is about.

See msg14344 and msg116479.
msg117138 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-22 13:13
And here is Martin's summary of the issue:

I think we really should create new issues for any remaining problems.

AFAICT, the remaining problems are:
- resource.RLIM_INFINITY is -1 on Linux, when it is meant to be
   a really large value
- (as you reported) getrlimit returns -1 to indicate RLIM_INFINITY.

I think the core of the problem is that the resource module considers
rlim_t to be a signed type (or at least representable in "long long").
Using FromUnsignedLongLong in the appropriate place might solve the
issue.
msg228039 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-09-30 23:56
@David one for your TODO list or does this rightfully belong with somebody else?
msg251771 - (view) Author: Arnon Yaari (wiggin15) * Date: 2015-09-28 16:28
getrlimit still returns -1 as 'max' when limit is unlimited and for RLIM_INFINITY because rlim_t is considered signed.

The zshell project decides whether rlim_t is signed/unsigned (and also whether it is long or long long) in the configure step: https://github.com/zsh-users/zsh/blob/8b84419f45298ee564bd6fa2b531c8991b2a1983/configure.ac#L1859

On Linux, rlim_t is unisnged long long so the conversion should be done using PyLong_FromUnsignedLongLong (for RLIM_INFINITY) and using 'KK' instead of 'LL' in 'rlimit2py'.

IMHO the best way to fix this is to add configure steps like in zsh and then adding ifdefs to resource.c - in rlimit2py and near PyModule_AddObject of RLIM_INFINITY
msg251802 - (view) Author: Arnon Yaari (wiggin15) * Date: 2015-09-28 21:53
I'm submitting a patch for review. I tested this and verified the values on Redhat and Unbuntu (both x86 and x64), Mac OS X (x64) and AIX (32-bit process on ppc64).
'configure' and 'pyconfig.h.in' were auto-generated with autoconf and autoheader, respectively.
A test for this patch (along with a fix for a different test failure) is in msg117130
msg255942 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-12-05 10:08
Are there platforms where rlim_t is signed? Posix defines it as unsigned: <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_resource.h.html>.

Also there are subtle differences between the PyLong_AsUnsigned[. . .] and the current signed versions. The unsigned version does not call __int__() so you would no longer be able to pass a float().

Also this could cause compatibility problems with code that was written for earlier documentation, which said to use -1 to mean unlimited. Perhaps that is why the code has rlim_* & RLIM_INFINITY masking.
History
Date User Action Args
2019-02-24 22:13:29BreamoreBoysetnosy: - BreamoreBoy
2015-12-05 10:08:07martin.pantersetnosy: + martin.panter
messages: + msg255942

components: + Extension Modules, - Library (Lib)
stage: needs patch -> patch review
2015-09-28 21:53:23wiggin15setfiles: + issue9917.diff
keywords: + patch
messages: + msg251802
2015-09-28 16:28:58wiggin15setnosy: + wiggin15
messages: + msg251771
2015-08-07 10:51:43giampaolo.rodolasetnosy: + giampaolo.rodola
2014-09-30 23:56:32BreamoreBoysetnosy: + BreamoreBoy

messages: + msg228039
versions: + Python 3.4, Python 3.5, - Python 3.1, Python 3.2
2010-09-22 13:13:46r.david.murraysetmessages: + msg117138
2010-09-22 01:42:54r.david.murraycreate