Re: [Xen-devel] [PATCH][TOOLS] libfsimage, pygrub, python: cleanup

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

John Levon writes ("Re: [Xen-devel] [PATCH][TOOLS] libfsimage, pygrub, python: 
cleanup"):
> On Tue, Jul 15, 2008 at 03:43:16PM +0200, [someone] wrote:
> >  fsi_plugin_ops_t *
> > +fsi_init_plugin(int version, fsi_plugin_t *fp, const char **name);
> > +
> > +fsi_plugin_ops_t *
> >  fsi_init_plugin(int version, fsi_plugin_t *fp, const char **name)
> 
> Huh? If some GCC option is insisting on this, it's a stupid option and
> shouldn't be enabled.

This is the result of (a) -Wmissing-prototypes, which is sensible
and (b) the submitter missing the point.

The purpose of -Wmissing-prototypes is to spot this situation:

  a.h:  double function(void);

  b.c:  #include "a.h"
        double some_caller(void) { return function(); }

  a.c:  int function(void) { return 1; }

The result of this is undefined behaviour, and neither the compiler
nor the linker will spot it.  If you pass -Wmissing-prototypes, then
the compiler will complain in a.c that there was no prototype for
function in scope.

This is supposed to clue you in to the missing #include.  You are
supposed to change a.c to this

  a.c:  #include "a.h"
        int function(void) { return 1; }

and now the compiler will tell you that your definition and
declaration of function do not match.

However if you don't understand this, you may do what the submitter of
this patch did, which is to change a.c to read like this:

  a.c:  int function(void);
        int function(void) { return 1; }

This completely defeats the point of -Wmissing-prototypes; I think
it's just wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel