From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 02CAC9ABE for ; Wed, 25 Feb 2015 06:38:00 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1P5bxOw028521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Feb 2015 00:37:59 -0500 Received: from localhost.localdomain (vpn1-4-57.ams2.redhat.com [10.36.4.57]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1P5bvUF028092; Wed, 25 Feb 2015 00:37:58 -0500 Message-ID: <54ED5FB6.3020608@redhat.com> Date: Wed, 25 Feb 2015 07:37:58 +0200 From: Panu Matilainen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Hemminger References: <1424700600-1765-1-git-send-email-pawelx.wodkowski@intel.com> <1424700600-1765-6-git-send-email-pawelx.wodkowski@intel.com> <20150223080035.001417e8@urahara> <54EC4261.6050804@redhat.com> <20150224110143.6be781f4@urahara> In-Reply-To: <20150224110143.6be781f4@urahara> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 5/5] Fix usage of fgets in various places 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, 25 Feb 2015 05:38:01 -0000 On 02/24/2015 09:01 PM, Stephen Hemminger wrote: > On Tue, 24 Feb 2015 11:20:33 +0200 > Panu Matilainen wrote: > >> The tool is technically correct, even if loss of precision might be >> unlikely to occur in this context > > Overflow is not there in the code. > That is why I said "shooting Unicorns"; this is all about > about fixing bugs that don't exist because there is nothing there > in the real world. > > In this code buffer is always something normal in size and does > not exceed 2^32-1. Oh, if the tool is complaining about fixed-size buffers then yeah the the tool is being silly, sorry I didn't actually look up the cases. - Panu -