On 06/21/2018 12:47 AM, Zack Weinberg wrote:
On Wed, Jun 20, 2018 at 4:40 PM, Florian Weimer <fweimer@redhat.com>
wrote:
On 05/22/2018 12:34 AM, Joseph Myers wrote:
On Mon, 21 May 2018, Zack Weinberg wrote:
No, this is an intentional deviation from the present state of POSIX,
anticipating the removal of those functions from the standard.
That would only seem relevant to the _XOPEN_CRYPT value in future POSIX
modes, not current ones.
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.
This is why I'm fine with Joseph's approach. It may even make it
marginally easier to check whether you need your own DES implementation.
I would like to see a decision soon because I'm wondering if I have to
back out the libxcrypt switch.