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
next prev parent 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