This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: _ATFILE_SOURCE Obsoletion


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,
>> which would mean fixing a lot of now broken packages that don't
>> build. Those packages would have to evaluate what needs to change,
>> find that they need to use _POSIX_C_SOURCE, at that point they
>> would have made a change which is equivalent to the deprecation
>> practice of defining the macro the superset feature but with a
>> warning.
> 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.

What is driving the deprecation/removal of _ATFILE_SOURCE in the first
place?  If it's simply mapped to the superset, the macro is still
supported in practice, the finer-grained feature set it represents is
lost, and I don't see what we really gain.

Rical


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]