On 22 Jun, 2010, at 19:05, Alexander Belopolsky wrote: > On Tue, Jun 22, 2010 at 12:39 PM, Ronald Oussoren > <ronaldousso...@mac.com> wrote: > .. >> Both are valid fixes, both have both advantages and disadvantages. >> >> Your proposal: >> * Reverts to the behavior in 2.6 >> * Ensures that posix.getgroups and posix.setgroups are internally consistent >> > It is also very simple and since posix module worked fine on OSX for > years without _DARWIN_C_SOURCE, I think this is a very low risk > change.
I don't agree. The patch itself is pretty simple, but it does make a rather
significant change to the build process: the compile-time environment in
configure would be different than during the compilation of posixmodule. That
is, in functions that check for features (the HAVE_FOOBAR macros in pyconfig.h)
would use _DARWIN_C_SOURCE while posixmodule itself wouldn't. This may lead
to subtle bugs, or even compile errors (because some function definitions
change when _DARWIN_C_SOURCE active).
And man compat(5) says:
<quote>
32-BIT COMPILATION
Defining _NONSTD_SOURCE causes library and kernel calls to behave as
closely to Mac OS X 10.3's library and kernel calls as possible. Any
behavioral changes in this mode are documented in the LEGACY sections of
the individual function calls.
Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel
calls to conform to the SUSv3 standards even if doing so would alter
the behavior of functions used in 10.3. Defining _POSIX_C_SOURCE also
removes functions, types, and other interfaces that are not part of
SUSv3 from the normal C namespace, unless _DARWIN_C_SOURCE is also defined
(i.e., _DARWIN_C_SOURCE is _POSIX_C_SOURCE with non-POSIX exten-
sions). In any of these cases, the _DARWIN_FEATURE_UNIX_CONFORMANCE
feature macro will be defined to the SUS conformance level (it is unde-
fined otherwise).
Starting in Mac OS X 10.5, if none of the macros _NONSTD_SOURCE,
_POSIX_C_SOURCE or _DARWIN_C_SOURCE are defined, and the environment vari-
able MACOSX_DEPLOYMENT_TARGET is either undefined or set to 10.5 or
greater (or equivalently, the gcc(1) option -mmacosx-version-min is
either not specified or set to 10.5 or greater), then UNIX conformance
will be on by default, and non-POSIX extensions will also be available
(this is the equivalent of defining _DARWIN_C_SOURCE). For version values
less that 10.5, UNIX conformance will be off (the equivalent of
defining _NONSTD_SOURCE).
</quote>
My interpretation of that is that _DARWIN_C_SOURCE should be used to get SUSv3
APIs while keeping access to darwin-specific API's at well. When you deploy to
10.5 or later the compiler will set _DARWIN_C_SOURCE for you unless you set one
of the other feature selecting defines.
>
>> My proposal:
>> * Uses the newer ABI, which is more likely to be the one Apple wants you to
>> use
>
> I don't think so. In getgroups(2) I see
>
> LEGACY DESCRIPTION
> If _DARWIN_C_SOURCE is defined, getgroups() can return more than
> {NGROUPS_MAX} groups.
>
> This suggests that this is legacy behavior. Newer applications should
> use getgrouplist instead.
I honestly don't know why this is in the LEGACY DESCRIPTION. But as the
functionality you get with _DARWIN_C_SOURCE was added later I'd say that the
behavior is intentional and not legacy. By not definining _DARWIN_C_SOURCE
we don't necessarily get full UNIX behavior for other APIs.
>
>> * Is compatible with system tools (that is, posix.getgroups() agrees with
>> id(1))
>
> I have not tested this recently, but I think if you exec id from a
> program after a call to setgroups(), it will return process groups,
> not user groups.
>
>> * Is compatible with /usr/bin/python
>
> I am sure that one this issue is fixed upstream, Apple will pick it up
> with the next version.
Haha. Apple explicitly added patches to get the current behavior instead of
the default, what makes you think that they'll revert to the older behavior.
>
>> * results in posix.getgroups not reflecting results of posix.setgroups
>>
>
> This effectively substitutes getgrouplist called on the current user
> for getgroups. In 3.x, I believe the correct action will be to
> provide direct access to getgrouplist which is while not POSIX (yet?),
> is widely available.
I don't mind adding getgrouplist, but that issue is seperator from this one.
BTW. Appearently getgrouplist is posix
(<http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/libc.html>),
although this isn't a requirement for being added to the posix module.
It is still my opinion that the second option is preferable for better
compatibility with system tools, even if the patch is more complicated and the
library function we use can be considered to be broken.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
