[PATCH] ctdb: Fix the O3 developer build

[Martin Schwenke]

On Thu, 14 Jan 2016 12:00:23 +0100, Volker Lendecke
<Volker.Lendecke at SerNet.DE> wrote:

> On Thu, Jan 14, 2016 at 09:46:12PM +1100, Martin Schwenke wrote:
> > On Thu, 14 Jan 2016 11:21:07 +0100, Volker Lendecke
> > <Volker.Lendecke at SerNet.DE> wrote:
> >   
> > > Review appreciated!  
> >   
> > > diff --git a/ctdb/server/ipalloc.c b/ctdb/server/ipalloc.c
> > > index 9b5579c..ae9e8de 100644
> > > --- a/ctdb/server/ipalloc.c
> > > +++ b/ctdb/server/ipalloc.c
> > > @@ -31,7 +31,7 @@
> > >  /* The calculation part of the IP allocation algorithm. */
> > >  bool ipalloc(struct ipalloc_state *ipalloc_state)
> > >  {
> > > -	bool ret;
> > > +	bool ret = false;
> > > 
> > >  	switch (ipalloc_state->algorithm) {
> > >  	case IPALLOC_LCP2:  
> > 
> > I'm just trying to understand why this type of fix is needed.  How do
> > I see the relevant errors or warnings?  Is there a tool that claims
> > there is a problem here? If so, is there a real problem or are we just
> > trying to avoid dodgy warnings?  :-)  
> 
> The tool is called gcc. It complains about a possibly uninitialized
> variable warning with CFLAGS="-O3", and with configure.developer we have
> this as an error.
> 
> Call them dodgy and broken tools, but that's what we have chosen for
> ourselves. We should eventuall convert to coding Samba in Rust, which
> is much smarter in this. The only problem is -- the march=c backend for
> llvm is no longer maintained.
> 
> > In this particular case the switch covers all the values of the enum,
> > so ret is always set, hence my lack of understanding.  I always
> > compile with --picky-developer, so I guess I'm trying to
> > understand what the O3 developer build is....  
> 
> It is a build with the -O3 optimization level. For gcc this enables
> more (and possibly completely broken) data flow analysis.

Thanks.  I didn't know that increasing the optimisation level causes
more warnings/errors.  That surprises me!

I guess I'll always configure with CFLAGS="-O3" when doing test builds.
I hope this catches a superset of potential errors and doesn't lose any
others...  ;-)

Thanks again for explaining...

peace & happiness,
martin