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

[Christoph Egger <Christoph.Egger@xxxxxxx>]

On Friday 18 July 2008 16:10:13 Ian Jackson wrote:
> 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.

When the submitter understands this, but misses a header where to put
the prototype into, then he tends to do so as a quick work around.
However, the submitter fully agrees, this belongs into a new header.
He is just asking what is the right directory and how to name the new
header filename.


Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


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