Re: Replace remaining StrNCpy() by strlcpy()
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-08-04T13:31:03Z
Lists: pgsql-hackers
Attachments
- v2-0001-Replace-remaining-StrNCpy-by-strlcpy.patch (text/plain) patch v2-0001
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
Commits
-
Replace remaining StrNCpy() by strlcpy()
- 1784f278a638 14.0 landed