Ronald Oussoren <ronaldousso...@mac.com> added the comment:

quoting compat(5) on OSX 10.6.2:

<quote>
     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 extensions).  In any of these cases, the 
_DARWIN_FEATURE_UNIX_CONFORMANCE feature macro
     will be defined to the SUS conformance level (it is undefined 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 variable 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>

If I read this correctly, this means that for deployment target 10.5 or later 
you must define _POSIX_C_SOURCE to get the correct version of getgroups, but 
that also hides all non-posix symbols in system headers. 

I haven't tested yet what the behavior is when neither _POSIX_C_SOURCE nor 
_DARWIN_C_SOURCE are defined (on OSX 10.4, 10.5 and 10.6).

BTW. It is possible to work around this by symbol renaming similarly to what 
Apple does in their headers to get the two variants of getgroups in the first 
place. But let's not go there unless there really is no other way.

As to your question "Why do you think this is what users expect to get when 
calling posix.getgroups()?": I'd expect that os.getgroups works just like it 
does in C code, and agrees with id(1). But then I'd also expect that 
os.setgroups affects the result of os.getgroups... Lame platform bugs are no 
fun :-(

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to