This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove __FAVOR_BSD
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: mtk dot manpages at gmail dot com, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Tue, 07 Jan 2014 11:27:45 +1300
- Subject: Re: Remove __FAVOR_BSD
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1312052315530 dot 16480 at digraph dot polyomino dot org dot uk> <20131216225338 dot 6FA7E7442E at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1312171726260 dot 14559 at digraph dot polyomino dot org dot uk> <20131217175318 dot AC4B674423 at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1312171808520 dot 14559 at digraph dot polyomino dot org dot uk> <CALxWeYoeTXG0uP-RPJdyU-kGBBOjQ5agT+GA4D0NRSKgHcvpNQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401061406570 dot 16360 at digraph dot polyomino dot org dot uk>
On 01/07/14 03:08, Joseph S. Myers wrote:
> On Mon, 6 Jan 2014, Michael Kerrisk wrote:
>
>> First of all, would this revised test for the feature_test_macros(7)
>> page be correct:
>>
>> _BSD_SOURCE
>> Defining this macro with any value causes header files
>> to expose BSD-derived definitions. In glibc versions up
>> to and including 2.18, defining this macro also causes
>> BSD definitions to be preferred in some situations where
>> standards conflict, unless one or more of _SVID_SOURCE,
>> _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE,
>> _XOPEN_SOURCE_EXTENDED, or _GNU_SOURCE is defined, in
>> which case BSD definitions are disfavored. Since glibc
>> 2.19, _BSD_SOURCE no longer causes BSD definitions to be
>> preferred in case of conflicts.
>
> Yes.
>
>> What do (admittedly, strange) programs that employ the BSD getpgrp()
>> and setpgrp() interfaces now do? It looks as though they'll require
>> source code changes to call a different API, right?
>
> Yes. Programs using BSD getpgrp, setpgrp, setjmp and sigpause will need
> source code changes.
So, do the following new man-page texts look okay to you?
setpgrp()/getpgrp() [in setpgid(3)]
The BSD-specific setpgrp() call, which takes arguments pid and
pgid, is is a wrapper function that calls
setpgid(pid, pgid)
Since glibc 2.19, the BSD-specific setpgrp() function is no
longer exposed by <unistd.h>; calls should be replaced with the
setpgid() call shown above.
The BSD-specific getpgrp() call, which takes a single pid argu-
ment, is a wrapper function that calls
getpgid(pid)
Since glibc 2.19, the BSD-specific getpgrp() function is no
longer exposed by <unistd.h>; calls should be replaced with
calls to the POSIX.1 getpgrp() which takes no arguments (if the
intent is to obtain the caller's PGID), or with the getpgid()
call shown above.
sigpause(3):
Glibc uses the BSD version if the _BSD_SOURCE feature test
macro is defined and none of _POSIX_SOURCE, _POSIX_C_SOURCE,
_XOPEN_SOURCE, _GNU_SOURCE, or _SVID_SOURCE is defined. Other-
wise, the System V version is used (and _XOPEN_SOURCE must be
defined to obtain the declaration). Since glibc 2.19, only the
System V version is exposed by <signal.h>; applications that
formerly used the BSD sigpause() should be amended to use sig-
suspend(2).
setjmp(3):
POSIX does not specify whether setjmp() will save the signal
mask (to be later restored during longjmp(3)). In System V it
will not. In 4.3BSD it will, and there is a function _setjmp
that will not. On Linux with glibc versions before 2.19,
setjmp() follows the System V behavior by default, but the BSD
behavior is provided if the _BSD_SOURCE feature test macro is
defined and none of _POSIX_SOURCE, _POSIX_C_SOURCE,
_XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, _GNU_SOURCE, or
_SVID_SOURCE is defined. Since glibc 2.19, <setjmp.h> exposes
only the System V version of setjmp(). Programs that need the
BSD semantics should replace calls to setjmp() with calls to
sigsetjmp() with a nonzero savesigs argument.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/