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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers