On 2/17/2017 3:05 PM, 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.
Since you are already updating that line, do you prefer to convert it to snprintf instead of above modification? > >> >> snprintf(ifr.ifr_name, IFNAMSIZ, "%s", pmd->name); >> >> /Bruce > > Regards, > Keith >
