Re: _ATFILE_SOURCE Obsoletion

[Rical Jasan <ricaljasan at pacific dot net>]

On 10/18/2017 05:39 PM, Zack Weinberg wrote:
> On Wed, Oct 18, 2017 at 1:46 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 10/18/2017 10:38 AM, Zack Weinberg wrote:
>>> On Wed, Oct 18, 2017 at 1:33 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> On 10/18/2017 07:34 AM, Michael Kerrisk (man-pages) wrote:
>>>>> Also, broadening the meaning of _ATFILE_SOURCE to imply
>>>>> _POSIX_C_SOURCE==200809L sems a little risky to me, in terms of
>>>>> possibly creating developer pain.
>>>>
>>>> That risk is balanced against the *removal* of _ATFILE_SOURCE, [...]
>>>
>>> A little extra caution is required when promoting anything to mean
>>> _POSIX_C_SOURCE=200809L because some older functions were *removed* at
>>> that conformance level.  I could see programs using _ATFILE_SOURCE to
>>> get openat, but still wanting to be able to use gettimeofday, for
>>> instance.
>>
>> Oh, that is a very good point. I had not considered the removal aspect.
> 
> Thinking about this some more, our default is (approximately)
> _POSIX_C_SOURCE=200809L "plus more stuff", so we could maybe make
> _ATFILE_SOURCE a no-op.  This would break programs that ask for
> _POSIX_C_SOURCE=200112L (or lower) + _ATFILE_SOURCE, but that might be
> less troublesome than breaking programs that *only* use
> _ATFILE_SOURCE.
> 
> Honestly, though, I think we need to do that audit Rical mentioned.

Packages on https://codesearch.debian.net/ that use _ATFILE_SOURCE, with
notes from an /extremely/ cursory survey:

gcc
glibc
python2.7 - appears to also define __USE_XOPEN2K8
pam - used by pam_namespace; no discernible default use of a superset
      uses AT_FDCWD, openat, fstatat, ...
      has an odd #ifndef ... #undef _GNU_SOURCE
elfutils - appears to also define __USE_XOPEN2K8
iproute2 - defines _GNU_SOURCE
linux - defines _GNU_SOURCE
qemu - at least conditionally uses utimensat (CONFIG_UTIMENSAT)
xmms2 - used by fstatat.c; no discernible default use of a superset
python-cffi - used in a demo
insserv - appears to conditionalize on HAS_*at and _ATFILE_SOURCE
android-platform-system-core - defines __USE_XOPEN2K8
openmpi - not sure what needed it...
hwloc - not sure here either
mercurial - seems to conditionalize on AT_SYMLINK_NOFOLLOW
audacity - includes its own copy of features.h
pypy - appears to also __USE_XOPEN2K8
valgrind - used in a test
ldc - sets _GNU_SOURCE to true
mpich - seems to have a copy of hwloc (see above)
systemtap - seems to account for _ATFILE_SOURCE*
newlib - says, "_ATFILE_SOURCE (implied by _POSIX_C_SOURCE >= 200809L)"
ocamlnet - defines _GNU_SOURCE
ksh - not sure what's going on here
dietlibc - seems subject to the same scoping issues (superset bloat)
spring - seems to include a copy of features.h
megaglest - seems to include a copy of features.h
manpages-de - note sure what's happening here
faketime - appears to conditionalize *at interfaces appropriately
libcsp - seems to account for whether *AT* things are defined
knot-resolver - see faketime
efl - appears to undef _ATFILE_SOURCE; conditions HAVE_ATFILE_SOURCE
android-tools - defines __USE_XOPEN2K8
fakechroot - conditionalized on HAVE_OPENAT64
bootchart2 - defines _GNU_SOURCE
libconvert-binary-c-perl - has a copy of features.h
netatalk - appears to undef *AT* things
util-vserver - defines _GNU_SOURCE
stress-ng - defines _GNU_SOURCE
uclibc - has a copy of features.h
diod - _XOPEN_SOURCE = 600
procenv - seems to conditionalize appropriately
fakeroot-ng - configure test for openat
telepathy-ring - defined in a test
fuse-posixov1 - also defines _GNU_SOURCE
likwid - unsure why defined
ocaml-extunix - not sure what's going on here either
bfs - defines _GNU_SOURCE and _DEFAULT_SOURCE

*systemtap seems to DTRT, in that it appears aware of the intricacies
between conformance modes and glibc versions.

I haven't found a copy of POSIX.1-2008 yet to check removed bits, but I
didn't go into that level of detail with any of the above packages
anyway---this was a superficial, note-taking pass, in the hopes it gives
the community a better idea of where we stand.

The wording in my notes is unfortunately inconsistent, but ~35 packages
(70%) seem like they would survive aliasing _ATFILE_SOURCE to the
POSIX.1-2008 superset without any negative ramifications.  It isn't my
intent to assert that the remaining packages wouldn't (survive); I just
didn't dig any deeper in those cases.  The pam_namespace module stands
out as a potential blocker, along with a couple packages' test cases.

Rical