From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86326 invoked by alias); 16 Apr 2018 15:11:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 86312 invoked by uid 89); 16 Apr 2018 15:11:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.2 spammy=hassle X-HELO: mx1.redhat.com Subject: Re: [PATCH] New configure option --disable-libcrypt. To: Zack Weinberg , libc-alpha@sourceware.org Cc: carlos@redhat.com, nmav@redhat.com References: <20180416013614.29962-1-zackw@panix.com> From: Florian Weimer Message-ID: Date: Mon, 16 Apr 2018 15:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180416013614.29962-1-zackw@panix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00268.txt.bz2 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 > #include > +#if USE_CRYPT > #include > +#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 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 , a program like #include #include 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