Tom Lane wrote:
You missed one return where the string needed to be freed. I've
applied this patch with that fix and a couple of cosmetic changes.
Thanks for the report and patch!
Thanks for the work and the keen eye!
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
I have found a small but annoying bug in libpq where
connection parameters are resolved via LDAP.
Hmm ... that's a bug all right, but why have the null-termination
inside the loop at all? Seems like it should look like
for (p = result, i = 0; values[i] != NULL; ++i)
Albe Laurenz laurenz.a...@wien.gv.at writes:
I have attached a new version of the patch that should address all known
problems.
You missed one return where the string needed to be freed. I've
applied this patch with that fix and a couple of cosmetic changes.
Thanks for the report and patch!
I have found a small but annoying bug in libpq where
connection parameters are resolved via LDAP.
There is a write past the end of a malloc'ed string which causes
memory corruption. The code and the bug are originally by me :^(
The attached patch fixes the problem in HEAD.
This should be
Albe Laurenz laurenz.a...@wien.gv.at writes:
I have found a small but annoying bug in libpq where
connection parameters are resolved via LDAP.
There is a write past the end of a malloc'ed string which causes
memory corruption. The code and the bug are originally by me :^(
Hmm ... that's a
... btw, shouldn't this function free the result string when it's done
with it? AFAICS that string is not returned to the caller, it's just
being leaked.
(I'll refrain from asking why it's creating the string in the first
place rather than parsing ldap_get_values_len's output as-is ...)
