Re: libpq not reentrant

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq not reentrant
Дата
Msg-id 6778.1011369848@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq not reentrant  (Federico Di Gregorio <fog@initd.org>)
Список 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 по дате отправления:

Предыдущее
От: Federico Di Gregorio
Дата:
Сообщение: Re: libpq not reentrant
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: libpq not reentrant