Re: libpq not reentrant - Mailing list pgsql-bugs

From Tom Lane
Subject Re: libpq not reentrant
Date
Msg-id 6778.1011369848@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq not reentrant  (Federico Di Gregorio <fog@initd.org>)
List pgsql-bugs
Federico Di Gregorio <fog@initd.org> writes:
> so the right library is already detected. the function is called
> des_crypt and is completely compatible with std. i think that a

>   AC_SEARCH_LIBS(crypto,  des_crypt)

> in configure.in will suffice. then:

>   #ifdef HAVE_DES_CRYPT
>   #define crypt des_crypt
>   #endif

Hmm.  If it uses the same API as crypt(), how can it be reentrant ---
is it malloc'ing the result string?  The resulting leak probably isn't
significant for libpq's purposes, but I'm curious to know.

> in the right file will do the trick. (i know this is not a real patch,
> sorry. i can make one later at home if you need.)

Please put together and test a complete patch.  I don't really care for
the #define crypt, BTW --- seems too likely to cause problems.  I'd
suggest #ifdef'ing around the call to crypt().

Also, if the result string is malloc'd, code along the lines of

    #ifdef HAVE_DES_CRYPT
        foo = des_crypt(...);
    #else
        foo = crypt(...);
    #endif

        ... use foo ...

    #ifdef HAVE_DES_CRYPT
        /* des_crypt returns malloc'd string */
        free(foo);
    #endif

doesn't seem too unreasonable.  Or even

    #ifdef HAVE_DES_CRYPT
        foo = des_crypt(...);
    #else
        foo = strdup(crypt(...));
    #endif

        ... use foo ...

        free(foo);

which would at least narrow the window for problems when using
non-reentrant crypt.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Federico Di Gregorio
Date:
Subject: Re: libpq not reentrant
Next
From: Bruce Momjian
Date:
Subject: Re: libpq not reentrant