From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4535 invoked by alias); 7 Dec 2010 23:04:04 -0000 Received: (qmail 4527 invoked by uid 22791); 7 Dec 2010 23:04:03 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_CP X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Dec 2010 23:03:58 +0000 Received: by wwi17 with SMTP id 17so464792wwi.12 for ; Tue, 07 Dec 2010 15:03:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.168.67 with SMTP id j45mr956656wel.101.1291763035424; Tue, 07 Dec 2010 15:03:55 -0800 (PST) Received: by 10.216.47.73 with HTTP; Tue, 7 Dec 2010 15:03:55 -0800 (PST) Date: Tue, 07 Dec 2010 23:04:00 -0000 Message-ID: Subject: nlmconv.c - warning: value computed is not used From: Bernd Jendrissek To: binutils Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00278.txt.bz2 In message <477B8342.60604@redhat.com> Nick Clifton wrote: >> .././binutils/nlmconv.c: In function 'main': >> .././binutils/nlmconv.c:1081: warning: value computed is not used >> >> but is it safe to ignore this warning? > >Possibly, but it is hard to be sure without being able to reproduce the bug. >(I tried with my local sources, but I did not see this warning). What does >line 1081 in nlmconv.c in your sources look like ? Is it this: > > strncpy (nlm_variable_header (outbfd)->oldThreadName, " LONG", > NLM_OLD_THREAD_NAME_LENGTH); > >[snip other alternative] This is it in my case. I'm using GCC 4.3.1, compiling binutils from a git mirror [*], and trying random things to make the warning go away (I'm not really interested in nlmconv itself, so I just #if 0'ed the call out), I found that replacing NLM_OLD_THREAD_NAME_LENGTH with 7 or more placated GCC; 6 and below (including the #definition or 5) provoked the warning. It's as if GCC insists that you write a buffer overflow bug! If GCC was somehow omniscient enough to reason that " LONG" never gets used, fine, but I don't see how this can be the case, as just a few lines later outbfd "escapes" out of main() into abfd_close(). I'd be happy to follow suggestions on how to investigate this, although trying later versions of GCC means getting quite a few ducks in a row. [*] commit message of the revision I was building says: commit 93cf20549fb5a4cd15cdf0e2a5d68b2f415eeceb Author: Nick Clifton Date: Fri Jul 16 14:52:14 2010 +0000 * corefile.c (core_sym_class): Fix handling of subprogram names and add support for cloned function names. (I fetched some more git bits but the code in the vicinity of the strncpy doesn't seem to have changed since July 16.)