| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-04 13:31:03 |
| Message-ID: | e7da7abc-3b55-3979-726c-72f91a3af0ce@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. There's even some code in coerce_type() that will
> complain about this:
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().
>> 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.
I will look into that separately.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Replace-remaining-StrNCpy-by-strlcpy.patch | text/plain | 14.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2020-08-04 14:08:07 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| Previous Message | Stephen Frost | 2020-08-04 13:05:06 | Re: Reduce/eliminate the impact of FPW |