From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 64EF52C0C for ; Fri, 1 Mar 2019 08:49:09 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 363DFB00066; Fri, 1 Mar 2019 07:49:08 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 1 Mar 2019 07:49:02 +0000 To: Stephen Hemminger , References: <20190228224754.26511-1-stephen@networkplumber.org> <20190228224754.26511-3-stephen@networkplumber.org> From: Andrew Rybchenko CC: Ferruh Yigit , Thomas Monjalon Message-ID: <8f248bd3-1ae6-c8a1-ee6e-37742bd6ea90@solarflare.com> Date: Fri, 1 Mar 2019 10:48:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190228224754.26511-3-stephen@networkplumber.org> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24462.003 X-TM-AS-Result: No-3.461400-8.000000-10 X-TMASE-MatchedRID: csPTYAMX1+EOwH4pD14DsPHkpkyUphL9UAjrAJWsTe9cU0dNErOD+t4z BXBaIg4Kl8ANyEhBoJvRSvo65H/LAiJcv5X7ObmJy6Tq4TybHo+0LVEBnI7x1QeLCIX046iBSrJ TO1VGhMF2+AZuxakJy89fuxSQqqSyyA1ihY42R28vj6wHfIGxyQhRCJFb9cus5x99q4kVOUh5RA 29TjvO6DU3HPhRrRy9/76CM4Z/MGblRxm3A2wKujl/1fD/GopdcmfM3DjaQLFR8RAUGq/SZ53Hu L2QMmcbrsrh4wbKcKXdQ3a61xeaGhw8axkkmHEln+Mmpu0GHe2gcbmU1XZMwvFI1UF7n3Gpx4wy g8MDbFcW1RpW1NjA8WB9J9Wmp4JwKoYcjABqDh/te2Kvs7lfvr0dvJkkR7PMSKH4sAD+nuho9K2 gV2/a4Ipl4zHOw4Cz/88gqR5wDWMo+S6dithsgkMMprcbiest X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--3.461400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24462.003 X-MDID: 1551426549-bHXV0isVFPsD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 2/2] ethdev: use strlcpy instead of snprintf on initialization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 07:49:09 -0000 On 3/1/19 1:47 AM, Stephen Hemminger wrote: > Don't need to use snprintf for simple name copy. > > Signed-off-by: Stephen Hemminger > --- > lib/librte_ethdev/rte_ethdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 95889ed206db..8bd54dcf58c1 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -459,7 +459,7 @@ rte_eth_dev_allocate(const char *name) > } > > eth_dev = eth_dev_get(port_id); > - snprintf(eth_dev->data->name, sizeof(eth_dev->data->name), "%s", name); > + strlcpy(eth_dev->data->name, name, RTE_ETH_NAME_MAX_LEN); Why is sizeof() substituted with RTE_ETH_NAME_MAX_LEN? I thought that sizeof() is the first choice in such cases since it is a bit more safer vs possible changes in the code. BTW, wouldn't it be more friendly to check name length on entry and reject if it is too long? (and same for rte_eth_dev_create()) I agree that strlcpy() should be used anyway. > eth_dev->data->port_id = port_id; > eth_dev->data->mtu = ETHER_MTU; >