From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id E15832B8C for ; Thu, 9 Mar 2017 16:23:18 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 09 Mar 2017 07:23:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,136,1486454400"; d="scan'208";a="73547874" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 09 Mar 2017 07:23:17 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.172]) by FMSMSX105.amr.corp.intel.com ([169.254.4.250]) with mapi id 14.03.0248.002; Thu, 9 Mar 2017 07:23:16 -0800 From: "Wiles, Keith" To: "Legacy, Allain (Wind River)" CC: "Wiles, Keith" , "Richardson, Bruce" , "Dumitrescu, Cristian" , "dev@dpdk.org" , "Jolliffe, Ian (Wind River)" Thread-Topic: [dpdk-dev] [PATCH 5/5] cfgfile: increase local buffer size for max name and value Thread-Index: AQHSk4ujU8n7SW57f0ikMyaP6AUIe6GNFhuA//+R5UCAAIkoAA== Date: Thu, 9 Mar 2017 15:23:16 +0000 Message-ID: References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <1488482971-170522-6-git-send-email-allain.legacy@windriver.com> <8258C19A-889A-475B-9F29-33949ABCF8EE@intel.com> <70A7408C6E1BFB41B192A929744D8523968E9F02@ALA-MBC.corp.ad.wrs.com> In-Reply-To: <70A7408C6E1BFB41B192A929744D8523968E9F02@ALA-MBC.corp.ad.wrs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.5.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <5975FDD2D46AF843BC2CFCD214339F4D@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 5/5] cfgfile: increase local buffer size for max name and value 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: Thu, 09 Mar 2017 15:23:19 -0000 > On Mar 9, 2017, at 9:16 AM, Legacy, Allain = wrote: >=20 >> -----Original Message----- >> From: Wiles, Keith [mailto:keith.wiles@intel.com] >> Sent: Thursday, March 09, 2017 8:46 AM >> Would this change still cause a failure and memory over write if the use= r >> decides to have very large string. Does the code check the lengths to ma= ke >> sure they are valid and return error? >>=20 >=20 > The fgets() is bounded by the size of the buffer and the subsequent valid= ation will raise an error if no newline was detected within the buffer ther= efore an overly long line will result in a failure. I have added a test ca= se in the v2 patchset in which I have added a unit test framework for this = library. >=20 > while (fgets(buffer, sizeof(buffer), f) !=3D NULL) { > char *pos =3D NULL; > size_t len =3D strnlen(buffer, sizeof(buffer)); > lineno++; > if ((len >=3D sizeof(buffer) - 1) && (buffer[len-1] !=3D '\n')) { > printf("Error line %d - no \\n found on string. " > "Check if line too long\n", lineno); > goto error1; > } >=20 > Does that satisfy your concern and qualify for you Ack? Acked-by: Keith Wiles Regards, Keith