Re: libpq not reentrant

Federico Di Gregorio <fog(at)initd(dot)org> writes:
> i can see ./configure trying to find a reentrant crypt and revert to a
> not-reentrant one only as a last resort.

Well, the lack of any man page for crypt_r on Linux doesn't give me a
warm feeling about its level of supportedness there. crypt_r() does
exist on HPUX, but there seems to be a little problem of compatibility.
I read in the Linux /usr/include/crypt.h:

#ifdef __USE_GNU
/* Reentrant versions of the functions above. The additional argument
points to a structure where the results are placed in. */
struct crypt_data
{
char keysched[16 * 8];
char sb0[32768];
char sb1[32768];
char sb2[32768];
char sb3[32768];
/* end-of-aligment-critical-data */
char crypt_3_buf[14];
char current_salt[2];
long int current_saltbits;
int direction, initialized;
};

extern char *crypt_r (__const char *__key, __const char *__salt,
struct crypt_data * __restrict __data) __THROW;

...

which immediately leaves one wondering whether __USE_GNU is defined by
default. But assuming it is, let's compare to HPUX, where the crypt
man page saith:

SYNOPSIS
#include <crypt.h>
#include <unistd.h>

char *crypt(const char *key, const char *salt);

char *crypt_r(const char *key, const char *salt, CRYPTD *cd);

...

Reentrant Interfaces
cd is a pointer to a CRYPTD object, which is defined in <crypt.h>.

For crypt_r(), cd is used as a buffer to store the result string.

So right off the bat, configure is going to have a task guessing
the correct type of the third argument to crypt_r. (Who knows what
it is on other Unixen...)

Given that as of 7.2, MD5 is the preferred password encryption method
and crypt() is deprecated, I'm not inclined to spend a lot of work
trying to develop a bulletproof autoconf procedure for making crypt
re-entrant. I'm strongly inclined to just document the problem and
leave it at that. Comments?

regards, tom lane