Re: libpq not reentrant

Federico Di Gregorio <fog@initd.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