Message73011
| Author |
loewis |
| Recipients |
jnoller, loewis, pitrou, roudkerk, skip.montanaro |
| Date |
2008年09月11日.09:51:59 |
| SpamBayes Score |
2.8267477e-10 |
| Marked as misclassified |
No |
| Message-id |
<1221126787.89.0.744550104201.issue3110@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
According to POSIX, if no determinate value for SEM_VALUE_MAX can be
given, the actual value should be queried with
sysconf(_SC_SEM_VALUE_MAX), and SEM_VALUE_MAX should not be defined;
this is in particular the case when the value depends on the system
configuration (such as available memory). _POSIX_SEM_VALUE_MAX specifies
the minimum value guaranteed by POSIX.
Now, it is not plausible why SEM_VALUE_MAX should vary by installation,
as it just depends on what integer type is used to represent the
counter. So more likely, Sun wrote its header files at a time when the
spec was not finished, so they didn't want to clutter the global namespace.
IOW, I think the patch is fine as it stands. If you are over-cautious,
you should test whether _SC_SEM_VALUE_MAX is defined, and use sysconf in
that case, and only fall back to _SEM_VALUE_MAX, then
_POSIX_SEM_VALUE_MAX, then fail, if sysconf isn't available.
If you do make this change, please stop using Py_BuildValue to convert a
C int to a Python int; use PyInt_FromLong instead. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2008年09月11日 09:53:08 | loewis | set | recipients:
+ loewis, skip.montanaro, pitrou, roudkerk, jnoller |
| 2008年09月11日 09:53:07 | loewis | set | messageid: <1221126787.89.0.744550104201.issue3110@psf.upfronthosting.co.za> |
| 2008年09月11日 09:52:01 | loewis | link | issue3110 messages |
| 2008年09月11日 09:52:00 | loewis | create |
|