From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replace remaining StrNCpy() by strlcpy() |
Date: | 2020-08-03 17:27:24 |
Message-ID: | 905987b9-b446-cfbb-8847-96c9c8d34027@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-08-03 14:12, Tom Lane wrote:
> I wrote:
>> David Rowley <dgrowleyml(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-03 17:39:15 | Re: Replace remaining StrNCpy() by strlcpy() |
Previous Message | Peter Geoghegan | 2020-08-03 17:15:48 | Re: new heapcheck contrib module |