GNU bug report logs - #14463
coreutils-8.21 darwin regressions

Previous Next

Full log

Message #20 received at 14463 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jack Howarth <howarth <at> bromo.med.uc.edu>
Cc: 14463 <at> debbugs.gnu.org
Subject: Re: bug#14463: coreutils-8.21 darwin regressions
Date: Sat, 25 May 2013 10:22:02 -0700

On 05/25/2013 07:51 AM, Jack Howarth wrote:
> I am a bit unclear on that issue. Does darwin lack the complete posix support required for
> freadahead.c, freadptr.c, fseterr.c and fseeko.c to be rewritten to support compiling with
> -D_POSIX_C_SOURCE (at least for modern darwin releases)? Or has it just never been implemented
> in order to maintain support for legacy versions of darwin?

Sorry, I don't know Darwin.  But my guess is that applications
routinely need to define _DARWIN_C_SOURCE to get their work
done.

I'm a bit puzzled by this case.  If I understand
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/compat.5.html
correctly, _DARWIN_C_SOURCE nowadays means "conform to POSIX,
but add non-POSIX extensions even if that violates the POSIX
namespace rules", which is normally what we want.  And yet here,
_DARWIN_C_SOURCE seems to mean "change getgroups() so that it
no longer works right".  What gives?  If Apple has
a little "POSIX world" to pacify the standards nerds, but it's
a world that actual programs would never really want to use,
then we don't want to use it either.

The BUGS section of that manual page says that the behavior
is dubious if you compile different sections of a program with
different flags, so I'd prefer a solution that didn't require
disabling _DARWIN_C_SOURCE just for this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.