| msg87192 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2009-05-05 00:24 |
| Simple patch to fix some gcc warnings (when using gcc -Wall -Wextra). |
|
|
| msg87193 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2009-05-05 00:26 |
| Another patch to fix similar warnings in resource modules. |
|
|
| msg87240 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2009-05-05 09:58 |
| About sign_warning_resource.patch: I don't know if RLIM_INFINITY constant is standard (always defined if getrlimit() is present). |
|
|
| msg87255 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-05 16:57 |
| Thanks for the patches. The first patch looks fine; I'll apply it shortly. For the second, I don't understand why you want to compare the return result with RLIM_INFINITY: PyInt_AsLong returns -1 to signal failure; is there some guarantee that RLIM_INFINITY == -1 if it's defined? |
|
|
| msg87266 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-05 18:10 |
| Applied the first patch in r72344, r72345, r72346, r72347. |
|
|
| msg87318 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2009-05-06 08:17 |
| > For the second, I don't understand why you want to > compare the return result with RLIM_INFINITY: PyInt_AsLong > returns -1 to signal failure; is there some guarantee that > RLIM_INFINITY == -1 if it's defined? rlim_t is an unsigned type. The idea of sign_warning_resource.patch was to make gcc quiet about signed/unsigned comparaisons. RLIM_INFINITY is defined as (rlim_t)-1. But it looks that it's not clear, so I wrote another patch to fix the warnings. |
|
|
| msg87338 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2009-05-06 16:28 |
| Yes, that looks better. PS: Do not remove applied patches. |
|
|
| msg87339 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2009-05-06 16:45 |
| > PS: Do not remove applied patches. Oh ok, sorry. |
|
|
| msg87471 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-08 21:15 |
| Applied in r72479, r72481, r72482, r72483. As a side note, I'm not 100% convinced of the correctness of the resource_setrlimit code. If rlim_t is smaller than an unsigned long then input values might be wrapped to a smaller value (by the implicit long -> rlim_t conversion) when they should be signaling OverflowError instead. Perhaps there should be a bunch of PySAFE_DOWNCASTs here? Or maybe rlim_t is never smaller than a long in practice. About RLIM_INFINITY: I can't find it documented anywhere that RLIM_INFINITY is (rlim_t)-1, though I dare say that's true on many platforms. Still, it doesn't seem like a safe assumption. |
|
|