Magnus Hagander [EMAIL PROTECTED] writes:
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just slow), but it
shows a rather bad bug in libpq.
[squint] That is the specified behavior of strncpy on every platform,
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just slow), but it
shows a rather bad bug in libpq.
[squint]
Magnus Hagander wrote:
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
Given this, I'll go ahead and fix fe-connect to support PQExpBuffers,
unless there are any objections.
I'm not against that, but I question what bug you've really found.
I never actually tested if it crashes on
Magnus Hagander [EMAIL PROTECTED] writes:
I also found at least one other place in libpq where it still does
fprintf(stderr). That should probably be fixed at the same time, right?
Yeah, we should be using the error message buffer if at all possible.
regards, tom lane
Magnus Hagander [EMAIL PROTECTED] writes:
I never actually tested if it crashes on mingw, but looking some more at it
it really should - once one of these errors happen.
Hm. Much easier than that - the code is new in HEAD. 8.2 did
fprintf(stderr). And HEAD still does that in at least one
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I never actually tested if it crashes on mingw, but looking some more at it
it really should - once one of these errors happen.
Hm. Much easier than that - the code is new in HEAD. 8.2 did
fprintf(stderr). And HEAD still does that in
