Re: Oops in fe-auth.c - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Oops in fe-auth.c
Date
Msg-id 20070723143600.GB4119@svr2.hagander.net
Whole thread Raw
In response to Re: Oops in fe-auth.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Oops in fe-auth.c  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> 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,
> not only msvc.  If there's a bug here why didn't we notice it long ago?

Hmm. Interesting - I see that now if I look at
http://www.opengroup.org/onlinepubs/007908799/xsh/strncpy.html.

That's very interesting - but my debugger very much shows me that the
buffer size is 256 bytes (INITIAL_EXPBUFFER_SIZE), and passes
1024 (PQERRORMSG_LENGTH) as the size of the buffer...

Perhaps we've just never hit one of those codepaths before. Previously, it
was only used for out of memory errors - the gssapi code adds a few places
where it's used in other cases, and this is where it crashed for me.

> > 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 mingw, but looking some more at it
it really should - once one of these errors happen.

//Magnus


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SSPI vs MingW
Next
From: Tom Lane
Date:
Subject: Re: Full page images in WAL & Cache Invalidation