[Python-Dev] red buildbots on 2.7

[Ronald Oussoren]

On 22 Jun, 2010, at 19:05, Alexander Belopolsky wrote:

> On Tue, Jun 22, 2010 at 12:39 PM, Ronald Oussoren
> <ronaldoussoren at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100623/557c57aa/attachment-0001.bin>