This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] New configure option --disable-crypt.
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Rical Jasan <rj at 2c3t dot io>, Thorsten Kukuk <kukuk at suse dot de>
- Date: Thu, 28 Jun 2018 14:52:30 -0400
- Subject: Re: [PATCH 4/4] New configure option --disable-crypt.
- References: <20180521173853.5172-1-zackw@panix.com> <20180521173853.5172-5-zackw@panix.com> <alpine.DEB.2.20.1805211950530.30181@digraph.polyomino.org.uk> <CAKCAbMi5-c+nrt3apH-rnvi1jX+4ShLJ140ZvzjqEGrcoETs9w@mail.gmail.com> <alpine.DEB.2.20.1805212226550.30181@digraph.polyomino.org.uk> <fa94a6a5-02af-4d60-fe8f-cd827ec8c1d3@redhat.com> <CAKCAbMgXmyZYpNXLoJHs1aJTT+E7OFakLC6PQGjsGh9Z5BcMwQ@mail.gmail.com> <622c0da0-630b-d81d-4c56-506fcc2493ef@redhat.com>
On Thu, Jun 21, 2018 at 5:31 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/21/2018 12:47 AM, Zack Weinberg wrote:
>> On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com>
>>>
>>> So we should stop defining _XOPEN_CRYPT, but continue to declare crypt in
>>> <unistd.h> for __USE_MISC || __USE_XOPEN? That would work for me.
>>
>>
>> Again, I think that it is inappropriate to stop defining _XOPEN_CRYPT
>> in any mode. Yes, this is an intentional deviation from POSIX, but I
>> think it is far less likely to break existing programs than the
>> alternative.
>
> How can we resolve this conflict?
>
> We have mostly cleaned up Fedora 28 to build with !_XOPEN_CRYPT already.
> There weren't many changes AFAICS, and they fall broadly into two
> categories:
>
> (1) Not including <crypt.h> for the crypt function, only <unistd.h>.
> (2) Using DES functions.
>
> (1) was far more common than (2).
>
> We'll keep the declaration of crypt in <unistd.h> for _DEFAULT_SOURCE, so
> (1) will not be a problem. (2) will not be addressed independently of the
> definition of _XOPEN_CRYPT.
Based on this I withdraw my objection. I was primarily worried about
programs that might substitute their own, possibly DES-only, crypt()
implementation if _XOPEN_CRYPT wasn't defined.
zw