On 2020-08-08 18:09, Tom Lane wrote:
Peter Eisentraut writes:
I removed namecpy() altogether because you can just use struct assignment.
Makes sense, and I notice it was unused anyway.
v3 passes eyeball examination (I didn't bother running tests), with
only one remaining nit: the proposed co
Peter Eisentraut writes:
> I removed namecpy() altogether because you can just use struct assignment.
Makes sense, and I notice it was unused anyway.
v3 passes eyeball examination (I didn't bother running tests), with
only one remaining nit: the proposed commit message says
They are equ
On 2020-08-05 17:49, Tom Lane wrote:
However I do see one remaining nit to pick, in CreateInitDecodingContext:
/* register output plugin name with slot */
SpinLockAcquire(&slot->mutex);
- StrNCpy(NameStr(slot->data.plugin), plugin, NAMEDATALEN);
+ namestrcpy(&slot->data
On Tue, 4 Aug 2020 at 00:12, Tom Lane wrote:
>
> I wrote:
> > David Rowley 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 z
Peter Eisentraut writes:
> Okay, here is a new patch with improved implementations of namecpy() and
> namestrcpy(). I didn't see any other places that relied on the
> zero-filling behavior of strncpy().
I've looked through this patch, and I concur with your conclusion that
noplace else is depe
On 2020-08-03 19:39, Tom Lane wrote:
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?
We do have an expectation that there are no undefined bytes in values to
be stored on-disk.
Peter Eisentraut writes:
> On 2020-08-03 14:12, Tom Lane wrote:
>> 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
On 2020-08-03 14:12, Tom Lane wrote:
I wrote:
David Rowley 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
I wrote:
> David Rowley 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
David Rowley writes:
> - StrNCpy(msg.m_xlog, xlog, sizeof(msg.m_xlog));
> + strlcpy(msg.m_xlog, xlog, sizeof(msg.m_xlog));
> 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 col
On Mon, 3 Aug 2020 at 18:59, Peter Eisentraut
wrote:
> I propose to replace the remaining uses of StrNCpy() with strlcpy() and
> remove the former. It's clear that strlcpy() has won the popularity
> contest, and the presence of the former is just confusing now.
It certainly would be good to get
11 matches
Mail list logo
