Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"nickc@redhat.com" <nickc@redhat.com>,
	"bug-binutils@gnu.org" <bug-binutils@gnu.org>
Subject: Re: [RFA] peXXigen.c, _bfd_XXi_swap_aux_in, wrong size used in memcpy.
Date: Thu, 03 Mar 2011 21:07:00 -0000	[thread overview]
Message-ID: <201103032107.10093.pedro@codesourcery.com> (raw)
In-Reply-To: <4D6FF4B4.9090601@vmware.com>

On Thursday 03 March 2011 20:06:12, Michael Snyder wrote:
> > 
> > Doesn't pe.h define them both the same?
> 
> Hmm, yes... Coverity was evidently looking at the definition of 
> E_FILNMLEN from include/coff/external.h, which is overridden by
> the one in pe.h.

Static analyser's output is always full of false positives.
Humans always need to filter it...

> >> Index: peXXigen.c
> >> ===================================================================
> >> RCS file: /cvs/src/src/bfd/peXXigen.c,v
> >> retrieving revision 1.69
> >> diff -u -p -u -p -r1.69 peXXigen.c
> >> --- peXXigen.c  21 Dec 2010 15:24:38 -0000      1.69
> >> +++ peXXigen.c  3 Mar 2011 18:03:44 -0000
> >> @@ -249,7 +249,7 @@ _bfd_XXi_swap_aux_in (bfd * abfd,
> >>           in->x_file.x_n.x_offset = H_GET_32 (abfd, ext->x_file.x_n.x_offset);
> >>         }
> >>        else
> >> -       memcpy (in->x_file.x_fname, ext->x_file.x_fname, FILNMLEN);
> >> +       memcpy (in->x_file.x_fname, ext->x_file.x_fname, E_FILNMLEN);
> >>        return;
> >>  
> >>      case C_STAT:
> >> @@ -323,7 +323,7 @@ _bfd_XXi_swap_aux_out (bfd *  abfd,
> >>           H_PUT_32 (abfd, in->x_file.x_n.x_offset, ext->x_file.x_n.x_offset);
> >>         }
> >>        else
> >> -       memcpy (ext->x_file.x_fname, in->x_file.x_fname, FILNMLEN);
> >> +       memcpy (ext->x_file.x_fname, in->x_file.x_fname, E_FILNMLEN);
> > 
> > If FILNMLEN can really be different from E_FILNMLEN, I'd've expected
> > something else needs doing here?
> 
> 
> Maybe this?

No.  Think about what it would mean if the source is
larger than the destination, or the opposite.

I think doing what coffswap.h does is more appropriate:

#if FILNMLEN != E_FILNMLEN
#error we need to cope with truncating or extending FILNMLEN
#else

If coverity doesn't handle this, well, report them a bug.

(I think binutils patches to go binutils@sourceware.org,
not bug-binutils@gnu.org)

-- 
Pedro Alves


  reply	other threads:[~2011-03-03 21:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 18:09 Michael Snyder
2011-03-03 19:13 ` Pedro Alves
2011-03-03 20:06   ` Michael Snyder
2011-03-03 21:07     ` Pedro Alves [this message]
2011-03-03 22:38     ` Alan Modra
2011-03-04 12:58 ` Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201103032107.10093.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=bug-binutils@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@vmware.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox