On 2020-08-03 14:12, Tom Lane wrote:
I wrote:
David Rowley <dgrowle...@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
