On 09/07/2011 10:33 PM, Bruno Haible wrote:
The crypt example is particularly annoying, as without _XOPEN_SOURCE defined it's not defined, even though POSIX_VERSION is>= 200112L, and it's in that version of POSIX (of course, that's a glibc bug
Setting _POSIX_C_SOURCE to 200809L _should_ automatically turn on _XOPEN_SOURCE of 700. (Setting it to 200112L sets _XOPEN_SOURCE to 600, but POSIX 2001 is 10 years old, and you're better off catering to POSIX 2008 these days).
$ cat foo.c #define _POSIX_C_SOURCE 200112L #include<unistd.h> $ gcc -E foo.c | grep crypt
Glibc bug. XSI shading means that a non-XSI implementation need not have crypt by default, but glibc is an XSI implementation, so requesting compliance with POSIX 2008 means that crypt() should be visible in <unistd.h>. There's no feature macro needed to turn on XSI functions - either you have an XSI system and they are all available by default, or you do not have an XSI system (usually embedded systems) and the system documents that it is not provide XSI.
Indeed crypt() is on POSIX:2001 <http://pubs.opengroup.org/onlinepubs/009604499/functions/crypt.html>. But it is marked as [XSI]. I don't know whether that implies that glibc is right in hiding the declaration, or it should enable it?
crypt() is also in POSIX 2008, and the bug still persists: $ printf '#define _POSIX_C_SOURCE 200809L\n#include <unistd.h>\n' \ | gcc -E - | grep crypt Would you care to raise a bug report against glibc?
Have I missed anything, or is this a gap in gnulib's coverage?
We could add a gnulib crypt module that exposes the declaration by default (basically, a stub module that depends on extensions, since the use of the extensions module is also sufficient to convince glibc to declare crypt).
Certainly the fact that crypt() is not defined by default could be mentioned in doc/posix-functions/crypt.texi. Bruno
-- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
