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 по дате отправления: