MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: text/plain; charset=UTF-8
Date: Thu, 28 May 2009 13:51:07 +0200
From: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Subject: Re: Compiler warning cleanup - unitilized const variables,
	pointer type mismatch
In-reply-to: <20090528113347.GB9247@feivel.credativ.lan>
To: Michael Meskes <meskes@postgresql.org>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Message-id: <1243511467.1372.43.camel@localhost>
References: <1243501880.1372.23.camel@localhost>
	<20090528113347.GB9247@feivel.credativ.lan>


Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200:
> On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote:
> > I attached another cleanup patch which fixes following warnings reported
> > by Sun Studio:
> > ...
> > "preproc.c", line 39569: warning: pointer expression or its operand do not point to the same object yyerror_range, result is undefined and non-portable 
> > ...
> > Following list is still unfixed plus see my comments:
> > 
> > "gram.c", line 28487: warning: pointer expression or its operand do not point to the same object yyerror_range, result is undefined and non-portable 
> > ...
> 
> These two should be the same, both coming from bison. Both files are
> auto-generated, thus it might be bison that has to be fixed to remove this
> warning. 

yeah it is generated, but question is if generated code is valid or it
is bug in bison. If it bison bug we need to care about it. There is the
code:

  yyerror_range[1] = yylloc;
  /* Using YYLLOC is tempting, but would change the location of
     the look-ahead.  YYLOC is available though.  */
  YYLLOC_DEFAULT (yyloc, (yyerror_range - 1), 2);
  *++yylsp = yyloc;

Problem is with YYLLOC_DEFAULT. When I look on macro definition 

#define YYLLOC_DEFAULT(Current, Rhs, N)          \
  Current.first_line   = Rhs[1].first_line;      \
  Current.first_column = Rhs[1].first_column;    \
  Current.last_line    = Rhs[N].last_line;       \
  Current.last_column  = Rhs[N].last_column;

It seems to me that it is OK, because 1 is used as a index which finally
point on yyerror_range[0]. 


> Given that I didn't find any mentioning of preproc in your patch I
> suppose it just hit the wrong list though.

I'm sorry copy paste error. Yeah, I did not fix preproc too.

		Zdenek