[PATCH] New configure option --disable-libcrypt.

[Florian Weimer]

On 04/16/2018 03:36 AM, Zack Weinberg wrote:
> diff --git a/elf/tst-linkall-static.c b/elf/tst-linkall-static.c
> index e8df38f74e..0ffae7c723 100644
> --- a/elf/tst-linkall-static.c
> +++ b/elf/tst-linkall-static.c
> @@ -18,7 +18,9 @@
>   
>   #include <math.h>
>   #include <pthread.h>
> +#if USE_CRYPT
>   #include <crypt.h>
> +#endif

The #include should be indented.

> diff --git a/posix/unistd.h b/posix/unistd.h
> index 4d149f9945..d9ac9d4c51 100644
> --- a/posix/unistd.h
> +++ b/posix/unistd.h
> @@ -107,9 +107,6 @@ __BEGIN_DECLS
>   /* The X/Open Unix extensions are available.  */
>   #define _XOPEN_UNIX	1
>   
> -/* Encryption is present.  */
> -#define	_XOPEN_CRYPT	1
> -
>   /* The enhanced internationalization capabilities according to XPG4.2
>      are present.  */
>   #define	_XOPEN_ENH_I18N	1
> @@ -1118,20 +1115,11 @@ ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
>   extern int fdatasync (int __fildes);
>   #endif /* Use POSIX199309 */
>   
> +/* The X/Open Encryption Option Group may or may not be supported in
> +   this release of the GNU C Library.  */
> +#include <bits/unistd-crypt.h>

Based on the Fedora experience, I wonder if it's not best to keep 
support _XOPEN_CRYPT unconditionally.  GCC still supports implicit 
function definitions by default and coerces the implied int return type 
to a pointer value.  This means that we drop the prototype from 
<unistd.h>, a program like

#include <stdio.h>
#include <unistd.h>

int
main (int argc, char **argv)
{
   return puts(crypt(argv[1], argv[2]));
}

still builds and links  successfully, but crashes at run time on 64-bit 
architectures.

 From a developer perspective, it would avoid a bit of hassle if we just 
said that if a distribution builds with --disable-libcrypt, it still 
needs to supply a compatible libcrypt with a definition of crypt and a 
default symbol version.

With encrypt and setkey, the situation is less pronounced because these 
functions are obsolete, and we can produce link errors if developers use 
them.

Thanks,
Florian