Re: Replace remaining StrNCpy() by strlcpy()

On 2020-08-03 14:12, Tom Lane wrote:
> I wrote:
>> David Rowley <dgrowleyml@gmail.com> writes:
>>> Will mean that we'll now no longer zero the full length of the m_xlog
>>> field after the end of the string. Won't that mean we'll start writing
>>> junk bytes to the stats collector?
> 
>> StrNCpy doesn't zero-fill the destination today either (except for
>> the very last byte).
> 
> Oh, no, I take that back --- didn't read all of the strncpy man
> page :-(.  Yeah, this is a point.  We'd need to check each call
> site to see whether the zero-padding matters.

Oh, that's easy to miss.

> In the specific case of the stats collector, if you don't want
> to be sending junk bytes then you'd better be memset'ing the
> whole message buffer not just this string field.  So I'm not
> sure that the argument has any force there.  But in places
> like namecpy() and namestrcpy() we absolutely do mean to be
> zeroing the whole destination buffer.

That's easy to fix, but it's perhaps wondering briefly why it needs to 
be zero-padded.  hashname() doesn't care, heap_form_tuple() doesn't 
care.  Does anything care?

While we're here, shouldn't namestrcpy() do some pg_mbcliplen() stuff 
like namein()?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services