Hello, Michael > The easiest way to perform tests with this patch is to take a debugger > and enforce the malloc'd pointers to NULL in the code paths.
I see. Still I don't think it's an excuse to not provide clear steps to reproduce an issue. As I see it anyone should be able to easily check your patch locally without having deep understanding of how libpq is implemented or reading thread which contains 48 e-mails. For instance you cold provide a step-by-step instruction like: 1. run gdb --args some-prog arg1 arg2 ... 2. b some_file.c:123 3. c 4. ... 5. we expect ... but actually see ... Or you cold automate these steps using gdb batch file: gdb --batch --command=gdb.script --args some-prog arg1 arg2 ... where gdb.script is: b some_file.c:123 c ... etc ... Naturally all of this is optional. But it will simplify both understanding and reviewing of this path. Thus chances that this patch will be accepted will be increased and time required for this will be reduced significantly. Best regards, Aleksander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
