This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch] Fix build warnings for GAS on mips-linux-gnu
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Iain Sandoe <iain at codesourcery dot com>, <binutils at sourceware dot org>
- Date: Tue, 10 Jul 2012 18:32:37 +0100
- Subject: Re: [Patch] Fix build warnings for GAS on mips-linux-gnu
- References: <6C17D860-E7DE-4E59-A4A9-E0F84CE39D0E@codesourcery.com> <20120618042218.GB28533@bubble.grove.modra.org> <alpine.DEB.1.10.1207091923490.19403@tp.orcam.me.uk> <20120710062520.GF3117@bubble.grove.modra.org>
On Tue, 10 Jul 2012, Alan Modra wrote:
> > > > P.S. As an aside, is it intentional that the fall-back specifications are not proper prototypes?
> > >
> > > Yes. It saves trouble with "const char *" vs. "char *", "unsigned
> > > long" vs. "unsigned int" and the like differences when we provide a
> > > declaration that doesn't match some system header declaration.
> >
> > Hmm, two issues here:
> >
> > 1. Does it really matter given that the actual purpose of these fallback
> > declarations is to address the case where there are no respective
> > system-header declarations or prototypes in the first place (assuming
> > of course that e.g. sizeof (unsigned long) equals sizeof (unsigned
> > int) where applicable)?
>
> I think the failure mode was in cases where the HAVE_* macros were not
> defined for some reason even though the system headers have a
> declaration.
But that would be a bug in our configury then (such as one observed by
Iain), and there is no guarantee that the implicit types are going to be
compatible with ones actually used by the system in question. So unless
I'm missing something I think that papering over this problem so that code
builds at all (presumably in the interest of the unfortunate user to hit
it) is questionable.
> > 2. How does it play with -Werror that we use? -- these "function
> > declaration isn't a prototype" warnings will be turned into errors
> > defeating the purpose of these fallback declarations.
>
> Yes, --disable-werror will need to be used.
Fair enough here.
Maciej