Skip site navigation (1) Skip section navigation (2)

Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
Date: 2009-05-28 11:51:07
Message-ID: 1243511467.1372.43.camel@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
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



In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-05-28 12:20:13
Subject: Re: User-facing aspects of serializable transactions
Previous:From: Michael MeskesDate: 2009-05-28 11:33:47
Subject: Re: Compiler warning cleanup - unitilized constvariables, pointer type mismatch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group