Ronald Oussoren <[email protected]> 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 <[email protected]>
<http://bugs.python.org/issue7900>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
