From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replace remaining StrNCpy() by strlcpy() |
Date: | 2020-08-03 17:39:15 |
Message-ID: | 2358152.1596476355@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> 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 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?
We do have an expectation that there are no undefined bytes in values to
be stored on-disk. There's even some code in coerce_type() that will
complain about this:
* For pass-by-reference data types, repeat the conversion to see if
* the input function leaves any uninitialized bytes in the result. We
* can only detect that reliably if RANDOMIZE_ALLOCATED_MEMORY is
* enabled, so we don't bother testing otherwise. The reason we don't
* want any instability in the input function is that comparison of
* Const nodes relies on bytewise comparison of the datums, so if the
* input function leaves garbage then subexpressions that should be
* identical may not get recognized as such. See pgsql-hackers
* discussion of 2008-04-04.
> While we're here, shouldn't namestrcpy() do some pg_mbcliplen() stuff
> like namein()?
Excellent point --- probably so, unless the callers are all truncating
in advance, which I doubt.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Wolfgang Walther | 2020-08-03 17:44:53 | Re: Allow an alias to be attached directly to a JOIN ... USING |
Previous Message | Peter Eisentraut | 2020-08-03 17:27:24 | Re: Replace remaining StrNCpy() by strlcpy() |