Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
Date
Msg-id 1243511467.1372.43.camel@localhost
Whole thread Raw
In response to Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch  (Michael Meskes <meskes@postgresql.org>)
Responses Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch  (Michael Meskes <meskes@postgresql.org>)
List 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,
resultis 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,
resultis 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
availablethough.  */ 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




pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
Next
From: Peter Eisentraut
Date:
Subject: Re: User-facing aspects of serializable transactions