From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E41815683 for ; Wed, 11 May 2016 13:51:32 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 11 May 2016 04:51:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,608,1455004800"; d="scan'208";a="973418037" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 11 May 2016 04:51:32 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 11 May 2016 04:51:31 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 11 May 2016 04:51:31 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.104]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.148]) with mapi id 14.03.0248.002; Wed, 11 May 2016 19:51:29 +0800 From: "Yang, Ziye" To: "Richardson, Bruce" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] librte_eal: fix wrong args operation in eal_parse_args Thread-Index: AQHRq3fRt5tx4BZwn0SsQbZFarC2gJ+znuJA Date: Wed, 11 May 2016 11:51:28 +0000 Message-ID: References: <1462944501-15852-1-git-send-email-ziye.yang@intel.com> <20160511112451.GA18868@bricha3-MOBL3> In-Reply-To: <20160511112451.GA18868@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] librte_eal: fix wrong args operation in eal_parse_args X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 11:51:33 -0000 Hi Bruce, Could it be fixed later? If not, it should be documented. I faced this iss= ued today, and found that dpdk changed my last arg. In my mind, dpdk shoul= d not change the argv[last], which will confuse the users. Best Regards, Ziye Yang -----Original Message----- From: Richardson, Bruce=20 Sent: Wednesday, May 11, 2016 7:25 PM To: Yang, Ziye Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] librte_eal: fix wrong args operation in eal= _parse_args On Wed, May 11, 2016 at 01:28:21PM +0800, Ziye Yang wrote: > This patch is used to fix wrong operation on user input args.=20 > eal_parse_args function should not operate the args passed by the=20 > user. If the element in argv is generated by malloc function, changing=20 > it will cause memory issues when free the args. >=20 > Signed-off-by: Ziye Yang > --- > lib/librte_eal/bsdapp/eal/eal.c | 2 -- > lib/librte_eal/linuxapp/eal/eal.c | 2 -- > 2 files changed, 4 deletions(-) >=20 > diff --git a/lib/librte_eal/bsdapp/eal/eal.c=20 > b/lib/librte_eal/bsdapp/eal/eal.c index 06bfd4e..0eef92d 100644 > --- a/lib/librte_eal/bsdapp/eal/eal.c > +++ b/lib/librte_eal/bsdapp/eal/eal.c > @@ -420,8 +420,6 @@ eal_parse_args(int argc, char **argv) > goto out; > } > =20 > - if (optind >=3D 0) > - argv[optind-1] =3D prgname; > ret =3D optind-1; > =20 > out: > diff --git a/lib/librte_eal/linuxapp/eal/eal.c=20 > b/lib/librte_eal/linuxapp/eal/eal.c > index 8aafd51..ba9d1ac 100644 > --- a/lib/librte_eal/linuxapp/eal/eal.c > +++ b/lib/librte_eal/linuxapp/eal/eal.c > @@ -658,8 +658,6 @@ eal_parse_args(int argc, char **argv) > goto out; > } > =20 > - if (optind >=3D 0) > - argv[optind-1] =3D prgname; > ret =3D optind-1; > =20 > out: This is a behaviour change in DPDK. The behaviour has always been that afte= r calling eal init, you can update your argv/argc values by the number of a= rgs parsed and then parse your app args as normal, since argv[0] will still= point to your program name. While I agree that having the current behaviou= r may cause some problems, changing this behaviour may break applications t= hat have been written to use the existing behaviour. Since it is only the last EAL parameter arg that is modified, I think it wo= uld be acceptable to have the behaviour well documented and then expect any= app to store a second copy of the pointer to be modified if it is needed f= or a subsequent free call, for example. /Bruce