On Tue, Mar 14, 2006 at 03:12:29PM -0800, Ben Pfaff wrote:
> Ron <[EMAIL PROTECTED]> writes:
> 
> > With my current gcc (4.0.2-10), the following code:
> >
> >  int main() { return 0; }
> >
> > Will warn: function declaration isn't a prototype
> > if compiled with -Wstrict-prototypes.
> >
> > Since that is the signature for main which autoconf wraps its tests in
> > when creating conftest.c -- then tests which should normally succeed,
> > will fail if the language is C, and CPPFLAGS include -Wstrict-prototypes,
> > and -Werror (the latter being my preferred habit for release builds).
> 
> It's not reasonable to expect autoconf to work properly with
> -Werror.  When the next version of GCC comes out, it may add any
> number of new warnings for code that is currently accepted
> silently.  Autoconf doesn't have any way to predict what these
> new warnings will be.

That is quite true, but I'm not sure it isn't contrary to your
initial assertion...

If the reason that autoconf now compiles headers instead of just
preprocessing them, is 'realism' -- something they seem to emphasise
quite a lot -- then surely any new warning in an existing test is
a good thing to know and fix as well.

I'm not suggesting -Werror should be the default for autoconf,
just asking that it have a _chance_ of working, without something
as fundamental as an illegal (or at least non-standard) main()
function getting in the way.

> I too like to use -Werror for writing code.  But I don't pass it
> to Autoconf.  And I recommend that you not do so as well.

If you can assure me that this is the opinion of upstream, and/or
offer a good reason to not use one of the standard signatures for
main (which seems like a no-brainer in every respect otherwise),
then I might understand this.

Otherwise, don't you think it is the sort of thing we ought to
punt to them before ruling it out so summarily?  Or do you speak
with an upstream hat to wear?

I agree there are times and places you may prefer to ignore some
warnings, but taking the choice away entirely seems wrong...

cheers,
Ron



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to