procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge from gnulib, incorporating:

Browse source 
2013-11-13 getgroups: work around _DARWIN_C_SOURCE problem
* lib/getgroups.c: Update from gnulib.
This commit is contained in:
Paul Eggert 2013-11-27 15:58:03 -08:00
parent 336b7334b7
commit de27f8abfd
2 changed files with 21 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
ChangeLog
View file

@ -1,3 +1,9 @@
2013-11-27 Paul Eggert <eggert@cs.ucla.edu>
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 <rgm@gnu.org>
Move ja-dic, quail, leim-list.el from leim to lisp/leim.

15
lib/getgroups.c
View file

@ -43,6 +43,21 @@ getgroups (int n _GL_UNUSED, GETGROUPS_T *groups _GL_UNUSED)
# 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