On Fri, Feb 17, 2017 at 03:05:40PM +0000, Wiles, Keith wrote: > > > On Feb 17, 2017, at 9:02 AM, Richardson, Bruce <bruce.richard...@intel.com> > > wrote: > > > > On Fri, Feb 17, 2017 at 08:44:26AM -0600, Keith Wiles wrote: > >> Calling strncpy with a maximum size argument of 16 bytes on destination > >> array "ifr.ifr_ifrn.ifrn_name" of size 16 bytes might leave the > >> destination string unterminated. > >> > >> Signed-off-by: Keith Wiles <keith.wi...@intel.com> > >> --- > >> drivers/net/tap/rte_eth_tap.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > >> index efc4426..f9938d7 100644 > >> --- a/drivers/net/tap/rte_eth_tap.c > >> +++ b/drivers/net/tap/rte_eth_tap.c > >> @@ -297,7 +297,7 @@ tap_link_set_flags(struct pmd_internals *pmd, short > >> flags, int add) > >> return -1; > >> } > >> memset(&ifr, 0, sizeof(ifr)); > >> - strncpy(ifr.ifr_name, pmd->name, IFNAMSIZ); > >> + strncpy(ifr.ifr_name, pmd->name, IFNAMSIZ-1); > > This is why I always prefer to use snprintf for copying strings, you > > can't avoid null terminating. > > Normally I use snprintf to not sure why I reverted to strncpy. Maybe leftover > from a previous driver I used as the template. > Is there a case to be made that DPDK should provide a strlcpy function in the linuxapp EAL? [Assuming we don't want a dependency on libbsd?] I find strncpy a horribly-error prone function to use - worse than strcpy, since it gives a false sense of safety.
/Bruce
