[Emacs-diffs] trunk r115264: Merge from gnulib, incorporating:

[Paul Eggert]

------------------------------------------------------------
revno: 115264
revision-id: address@hidden
parent: address@hidden
committer: Paul Eggert <address@hidden>
branch nick: trunk
timestamp: Wed 2013-11-27 15:58:03 -0800
message:
  Merge from gnulib, incorporating:
  
  2013-11-13 getgroups: work around _DARWIN_C_SOURCE problem
  * lib/getgroups.c: Update from gnulib.
modified:
  ChangeLog                      changelog-20091113204419-o5vbwnq5f7feedwu-1538
  lib/getgroups.c                getgroups.c-20121114044639-6884lvvwce8v0sgb-5

=== modified file 'ChangeLog'
--- a/ChangeLog 2013-11-27 06:28:18 +0000
+++ b/ChangeLog 2013-11-27 23:58:03 +0000
@@ -1,3 +1,9 @@
+2013-11-27  Paul Eggert  <address@hidden>
+
+       Merge from gnulib, incorporating:
+       2013-11-13 getgroups: work around _DARWIN_C_SOURCE problem
+       * lib/getgroups.c: Update from gnulib.
+
 2013-11-27  Glenn Morris  <address@hidden>
 
        Move ja-dic, quail, leim-list.el from leim to lisp/leim.

=== modified file 'lib/getgroups.c'
--- a/lib/getgroups.c   2013-09-19 21:40:08 +0000
+++ b/lib/getgroups.c   2013-11-27 23:58:03 +0000
@@ -43,6 +43,21 @@
 #  define GETGROUPS_ZERO_BUG 0
 # endif
 
+/* On OS X 10.6 and later, use the usual getgroups, not the one
+   supplied when _DARWIN_C_SOURCE is defined.  _DARWIN_C_SOURCE is
+   normally defined, since it means "conform to POSIX, but add
+   non-POSIX extensions even if that violates the POSIX namespace
+   rules", which is what we normally want.  But with getgroups there
+   is an inconsistency, and _DARWIN_C_SOURCE means "change getgroups()
+   so that it no longer works right".  The BUGS section of compat(5)
+   says that the behavior is dubious if you compile different sections
+   of a program with different _DARWIN_C_SOURCE settings, so fix only
+   the offending symbol.  */
+# ifdef __APPLE__
+int posix_getgroups (int, gid_t []) __asm ("_getgroups");
+#  define getgroups posix_getgroups
+# endif
+
 /* On at least Ultrix 4.3 and NextStep 3.2, getgroups (0, NULL) always
    fails.  On other systems, it returns the number of supplemental
    groups for the process.  This function handles that special case