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
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
yyerror_range = 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.first_line; \
Current.first_column = Rhs.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.
> 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.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2009-05-28 12:20:13|
|Subject: Re: User-facing aspects of serializable transactions|
|Previous:||From: Michael Meskes||Date: 2009-05-28 11:33:47|
|Subject: Re: Compiler warning cleanup - unitilized constvariables, pointer type mismatch|