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

Hi!

Attached patch makes functions static which have no prototypes
in libfsimage, pygrub and in python.
It also adds prototypes to exported symbols.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Jul 15, 2008 at 03:43:16PM +0200, Christoph Egger 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.

regards
john

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Jul 18, 2008 at 03:10:13PM +0100, Ian Jackson 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)
> 
> The purpose of -Wmissing-prototypes is to spot this situation:
Indeed.
> 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.
It doesn''t even make sense for the compiler to warn about the above
though. It''s not called anywhere (that the compiler can detect:
certainly not in that C file).

regards
john

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

Christoph Egger wrote:
> 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.
I think the convention is to call all new headers "xen.h", and have it
include some subset of the other xen.hs in a confusing fashion.

    J

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