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 4AC449ADD for ; Tue, 24 Feb 2015 10:20:39 +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 t1O9KZ73020644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 24 Feb 2015 04:20:37 -0500 Received: from localhost.localdomain (vpn1-4-61.ams2.redhat.com [10.36.4.61]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1O9KYrw025562; Tue, 24 Feb 2015 04:20:34 -0500 Message-ID: <54EC4261.6050804@redhat.com> Date: Tue, 24 Feb 2015 11:20:33 +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 , Pawel Wodkowski References: <1424700600-1765-1-git-send-email-pawelx.wodkowski@intel.com> <1424700600-1765-6-git-send-email-pawelx.wodkowski@intel.com> <20150223080035.001417e8@urahara> In-Reply-To: <20150223080035.001417e8@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: Tue, 24 Feb 2015 09:20:39 -0000 On 02/23/2015 06:00 PM, Stephen Hemminger wrote: > On Mon, 23 Feb 2015 15:10:00 +0100 > Pawel Wodkowski wrote: > >> Declaration of fgets() is >> char *fgets(char *str, int size, FILE *stream); >> >> Klocwork complain about passing "sizeof()" as size parameter since >> implicit casting size_t to int might cause loss of precision. >> >> Signed-off-by: Pawel Wodkowski > > NAK this is shooting at Unicorns. > The tool is the problem not the code. The tool is technically correct, even if loss of precision might be unlikely to occur in this context. However the patch is incorrect, the problem doesn't go away by adding an explict cast even if it shuts up the tool. - Panu -