Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

Any progress on this? It appears to be needed for the latest Fedora, where they switched to gcc 8.1.

Because crypt() only depends on primitive C types, we currently get
away with calling it without it being declared.

Are you sure? Undeclared functions are assumed a return type of int while crypt() returns char *. I'm guessing that this might cause the Fedora 28 problem, which uses a different crypt library https://github.com/besser82/libxcrypt and does not declare crypt() in <unistd.h>

This PR does fix that problem.

Moreover, it's getting urgent, as there are plans to remove crypt() from glibc. Then calls to crypt without a prototype are doomed. You might convince yourself that it is so by trying to compile and run the following

/* cry.c */
#include <stdio.h>
#ifdef CRYP
#include <crypt.h>
#endif
int main()
{
char *word="blah";
char *salt="foo";
char *res;
res = crypt(word, salt);
printf("%s\n",res);
return 0;
}

Building (on a 64-bit Linux) with -DCRYP -lcrypt gives working program, building just with -lcrypt gives a program that segfaults.

Perhaps it makes sense to split this PR into two - one making crypt() properly tested for, the other adding crypt_r() use, if available.

Linking with libxcrypt is already fixed in https://bugs.python.org/issue32635

#11373 is a modern version of this. I'm waiting on the CI over there before merging it, but rather than anyone spending time updating and addressing conflicts in this one I'm just going to close it.

Our overall concepts are similar. I did the configure.ac check a bit differently to account for #define _GNU_SOURCE being required on Linux. The crypt.h was moved to Python.h a while back independent this PR so mine reuses that.