pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedCompiler warning cleanup - unitilized const variables, pointer type mismatch
10+ messages / 3 participants
[nested] [flat]
* Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 09:11 Zdenek Kotala <Zdenek.Kotala@Sun.COM>
0 siblings, 2 replies; 10+ messages in thread
From: Zdenek Kotala @ 2009-05-28 09:11 UTC (permalink / raw)
To: pgsql-hackers
I attached another cleanup patch which fixes following warnings reported
by Sun Studio:
"zic.c", line 1534: warning: const object should have initializer: tzh0
"dynloader.c", line 7: warning: empty translation unit
"pgstat.c", line 666: warning: const object should have initializer: all_zeroes
"pgstat.c", line 799: warning: const object should have initializer: all_zeroes
"pgstat.c", line 2552: warning: const object should have initializer: all_zeroes
"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
"tab-complete.c", line 587: warning: assignment type mismatch:
pointer to function(pointer to const char, int, int) returning pointer to pointer to char "=" pointer to void
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
- This is really strange warning. The code is really strange
because it points to -1 index of array, but I'm not bison guru.
Maybe it is correct, but it would be good if somebody check it.
"../../../src/include/pg_config.h", line 782: warning: macro redefined: _FILE_OFFSET_BITS
- This probably needs some extra love in configure.
"regc_lex.c", line 401: warning: loop not entered at top
"regc_lex.c", line 484: warning: loop not entered at top
"regc_lex.c", line 578: warning: loop not entered at top
"regc_lex.c", line 610: warning: loop not entered at top
"regc_lex.c", line 870: warning: loop not entered at top
"regc_lex.c", line 1073: warning: loop not entered at top
"postgres.c", line 3845: warning: loop not entered at top
- Assert on not reached place probably confuse compiler. I'm not
sure if it make sense nowadays? Most compiler should optimize
this anyway and code is removed. I suppose to remove these
asserts.
Zdenek
Attachments:
warning.patch (text/x-patch, 4.6K) download
diff -Nrc pgsql.orig.8fc4f032818a/src/backend/port/dynloader/solaris.c pgsql.orig/src/backend/port/dynloader/solaris.c
*** pgsql.orig.8fc4f032818a/src/backend/port/dynloader/solaris.c 2009-05-28 11:09:24.874020865 +0200
--- pgsql.orig/src/backend/port/dynloader/solaris.c 2009-05-28 11:09:24.893688008 +0200
***************
*** 5,7 ****
--- 5,11 ----
*
* see solaris.h
*/
+
+ /* compiler complains about empty unit, let compiler quite */
+ extern int no_such_variable;
+
diff -Nrc pgsql.orig.8fc4f032818a/src/backend/postmaster/pgstat.c pgsql.orig/src/backend/postmaster/pgstat.c
*** pgsql.orig.8fc4f032818a/src/backend/postmaster/pgstat.c 2009-05-28 11:09:24.882883806 +0200
--- pgsql.orig/src/backend/postmaster/pgstat.c 2009-05-28 11:09:24.894106321 +0200
***************
*** 662,669 ****
void
pgstat_report_stat(bool force)
{
! /* we assume this inits to all zeroes: */
! static const PgStat_TableCounts all_zeroes;
static TimestampTz last_report = 0;
TimestampTz now;
--- 662,668 ----
void
pgstat_report_stat(bool force)
{
! static const PgStat_TableCounts all_zeroes = {0,0,0,0,0,0,0,0,0,0,0};
static TimestampTz last_report = 0;
TimestampTz now;
***************
*** 795,802 ****
static void
pgstat_send_funcstats(void)
{
! /* we assume this inits to all zeroes: */
! static const PgStat_FunctionCounts all_zeroes;
PgStat_MsgFuncstat msg;
PgStat_BackendFunctionEntry *entry;
--- 794,800 ----
static void
pgstat_send_funcstats(void)
{
! static const PgStat_FunctionCounts all_zeroes = {0,{0,0},{0,0}};
PgStat_MsgFuncstat msg;
PgStat_BackendFunctionEntry *entry;
***************
*** 2548,2555 ****
void
pgstat_send_bgwriter(void)
{
! /* We assume this initializes to zeroes */
! static const PgStat_MsgBgWriter all_zeroes;
/*
* This function can be called even if nothing at all has happened. In
--- 2546,2552 ----
void
pgstat_send_bgwriter(void)
{
! static const PgStat_MsgBgWriter all_zeroes = { {0,0},0,0,0,0,0,0,0};
/*
* This function can be called even if nothing at all has happened. In
diff -Nrc pgsql.orig.8fc4f032818a/src/bin/psql/tab-complete.c pgsql.orig/src/bin/psql/tab-complete.c
*** pgsql.orig.8fc4f032818a/src/bin/psql/tab-complete.c 2009-05-28 11:09:24.890322342 +0200
--- pgsql.orig/src/bin/psql/tab-complete.c 2009-05-28 11:09:24.894581639 +0200
***************
*** 557,563 ****
/* Forward declaration of functions */
! static char **psql_completion(char *text, int start, int end);
static char *create_command_generator(const char *text, int state);
static char *drop_command_generator(const char *text, int state);
static char *complete_from_query(const char *text, int state);
--- 557,563 ----
/* Forward declaration of functions */
! static char **psql_completion(const char *text, int start, int end);
static char *create_command_generator(const char *text, int state);
static char *drop_command_generator(const char *text, int state);
static char *complete_from_query(const char *text, int state);
***************
*** 584,590 ****
initialize_readline(void)
{
rl_readline_name = (char *) pset.progname;
! rl_attempted_completion_function = (void *) psql_completion;
rl_basic_word_break_characters = "\t\n@$><=;|&{( ";
--- 584,590 ----
initialize_readline(void)
{
rl_readline_name = (char *) pset.progname;
! rl_attempted_completion_function = psql_completion;
rl_basic_word_break_characters = "\t\n@$><=;|&{( ";
***************
*** 603,609 ****
libraries completion_matches() function, so we don't have to worry about it.
*/
static char **
! psql_completion(char *text, int start, int end)
{
/* This is the variable we'll return. */
char **matches = NULL;
--- 603,609 ----
libraries completion_matches() function, so we don't have to worry about it.
*/
static char **
! psql_completion(const char *text, int start, int end)
{
/* This is the variable we'll return. */
char **matches = NULL;
diff -Nrc pgsql.orig.8fc4f032818a/src/timezone/zic.c pgsql.orig/src/timezone/zic.c
*** pgsql.orig.8fc4f032818a/src/timezone/zic.c 2009-05-28 11:09:24.893104510 +0200
--- pgsql.orig/src/timezone/zic.c 2009-05-28 11:09:24.894905527 +0200
***************
*** 1531,1537 ****
int timecnt32, timei32;
int pass;
static char *fullname;
! static const struct tzhead tzh0;
static struct tzhead tzh;
zic_t ats[TZ_MAX_TIMES];
unsigned char types[TZ_MAX_TIMES];
--- 1531,1537 ----
int timecnt32, timei32;
int pass;
static char *fullname;
! static const struct tzhead tzh0 = {0,0,0,0,0,0,0,0,0};
static struct tzhead tzh;
zic_t ats[TZ_MAX_TIMES];
unsigned char types[TZ_MAX_TIMES];
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 11:33 Michael Meskes <meskes@postgresql.org>
parent: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
1 sibling, 1 reply; 10+ messages in thread
From: Michael Meskes @ 2009-05-28 11:33 UTC (permalink / raw)
To: Zdenek Kotala <Zdenek.Kotala@Sun.COM>; +Cc: pgsql-hackers
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. Given that I didn't find any mentioning of preproc in your patch I
suppose it just hit the wrong list though.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 11:51 Zdenek Kotala <Zdenek.Kotala@Sun.COM>
parent: Michael Meskes <meskes@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: Zdenek Kotala @ 2009-05-28 11:51 UTC (permalink / raw)
To: Michael Meskes <meskes@postgresql.org>; +Cc: 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 12:47 Michael Meskes <meskes@postgresql.org>
parent: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
0 siblings, 2 replies; 10+ messages in thread
From: Michael Meskes @ 2009-05-28 12:47 UTC (permalink / raw)
To: Zdenek Kotala <Zdenek.Kotala@Sun.COM>; +Cc: Michael Meskes <meskes@postgresql.org>; pgsql-hackers
On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> 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].
Wait, this is the bison definition. Well to be more precise the bison
definition in your bison version. Mine is different:
# define YYLLOC_DEFAULT(Current, Rhs, N) \
do \
if (YYID (N)) \
{ \
(Current).first_line = YYRHSLOC (Rhs, 1).first_line; \
(Current).first_column = YYRHSLOC (Rhs, 1).first_column; \
(Current).last_line = YYRHSLOC (Rhs, N).last_line; \
(Current).last_column = YYRHSLOC (Rhs, N).last_column; \
} \
else \
{ \
(Current).first_line = (Current).last_line = \
YYRHSLOC (Rhs, 0).last_line; \
(Current).first_column = (Current).last_column = \
YYRHSLOC (Rhs, 0).last_column; \
} \
while (YYID (0))
Having said that, it doesn't really matter as we redefine the macro:
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
if (N) \
(Current) = (Rhs)[1]; \
else \
(Current) = (Rhs)[0]; \
} while (0)
I have to admit that those version look strikingly unsimilar to me. There is no
reference to Rhs[N] in our macro at all. But then I have no idea whether this
is needed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 14:34 Zdenek Kotala <Zdenek.Kotala@Sun.COM>
parent: Michael Meskes <meskes@postgresql.org>
1 sibling, 0 replies; 10+ messages in thread
From: Zdenek Kotala @ 2009-05-28 14:34 UTC (permalink / raw)
To: Michael Meskes <meskes@postgresql.org>; +Cc: pgsql-hackers
Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200:
> On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote:
> > 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].
>
> Wait, this is the bison definition. Well to be more precise the bison
> definition in your bison version. Mine is different:
I took it from documentation. I have same as you in generated code.
> # define YYLLOC_DEFAULT(Current, Rhs, N) \
> do \
> if (YYID (N)) \
> { \
> (Current).first_line = YYRHSLOC (Rhs, 1).first_line; \
> (Current).first_column = YYRHSLOC (Rhs, 1).first_column; \
> (Current).last_line = YYRHSLOC (Rhs, N).last_line; \
> (Current).last_column = YYRHSLOC (Rhs, N).last_column; \
> } \
> else \
> { \
> (Current).first_line = (Current).last_line = \
> YYRHSLOC (Rhs, 0).last_line; \
> (Current).first_column = (Current).last_column = \
> YYRHSLOC (Rhs, 0).last_column; \
> } \
> while (YYID (0))
>
> Having said that, it doesn't really matter as we redefine the macro:
>
> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> do { \
> if (N) \
> (Current) = (Rhs)[1]; \
> else \
> (Current) = (Rhs)[0]; \
> } while (0)
>
> I have to admit that those version look strikingly unsimilar to me. There is no
> reference to Rhs[N] in our macro at all. But then I have no idea whether this
> is needed.
Current is only int. See gramparse.h. I think we could rewrite it this
way:
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
if (N) \
(Current) = (Rhs)[1]; \
else \
(Current) = (Rhs)[N]; \
} while (0)
It is same result and compiler is quite.
Zdenek
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 15:42 Tom Lane <tgl@sss.pgh.pa.us>
parent: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2009-05-28 15:42 UTC (permalink / raw)
To: Zdenek Kotala <Zdenek.Kotala@Sun.COM>; +Cc: pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> I attached another cleanup patch which fixes following warnings reported
> by Sun Studio:
I'm not too impressed with any of these. The proposed added
initializers just increase future maintenance effort without solving
any real problem (since the variables are required by C standard to
initialize to zero). The proposed signature change on psql_completion
is going to replace a warning on your system with outright failures on
other people's.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-28 15:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael Meskes <meskes@postgresql.org>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2009-05-28 15:57 UTC (permalink / raw)
To: Michael Meskes <meskes@postgresql.org>; +Cc: Zdenek Kotala <Zdenek.Kotala@Sun.COM>; pgsql-hackers
Michael Meskes <meskes@postgresql.org> writes:
> I have to admit that those version look strikingly unsimilar to me. There is no
> reference to Rhs[N] in our macro at all. But then I have no idea whether this
> is needed.
The default version of the macro is intended to track both the starting
and ending locations of every construct. Our simplified version only
tracks the starting locations. The inputs are RHS[k], the location
values for the constituent elements of the current production, and
the output is the location value for the construct being formed.
In the default version, you naturally want to copy the start of
RHS[1] and the end of RHS[N], where N is the number of production
elements. In ours, we just copy the location of RHS[1]. However,
both macros need a special case for empty productions (with N = 0).
AFAICS, Sun's compiler is just too stupid and shouldn't be emitting
this warning. Perhaps the right response is to file a bug report
against the compiler.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-29 12:36 Zdenek Kotala <Zdenek.Kotala@Sun.COM>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Zdenek Kotala @ 2009-05-29 12:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > I attached another cleanup patch which fixes following warnings reported
> > by Sun Studio:
>
> I'm not too impressed with any of these. The proposed added
> initializers just increase future maintenance effort without solving
> any real problem (since the variables are required by C standard to
> initialize to zero).
Agree.
> The proposed signature change on psql_completion
> is going to replace a warning on your system with outright failures on
> other people's.
I check readline and definition is still same at least from 5.0 version.
I'm not still understand why it should failure on other systems. I
looked on revision 1.30 of the file and there is only readline-4.2
support mentioned. Is readline 4.2 the problem?
Zdenek
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-29 12:44 Zdenek Kotala <Zdenek.Kotala@Sun.COM>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 10+ messages in thread
From: Zdenek Kotala @ 2009-05-29 12:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Meskes <meskes@postgresql.org>; pgsql-hackers
Tom Lane píše v čt 28. 05. 2009 v 11:57 -0400:
> ).
>
> AFAICS, Sun's compiler is just too stupid and shouldn't be emitting
> this warning. Perhaps the right response is to file a bug report
> against the compiler.
I checked it and it is already know bug. It is new lint style check in
Sun Studio 12. Unfortunately, problem is that current workflow does not
allow to detect if code is dead or not in the verification phase. Next
sun studio release could fix it.
Zdenek
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
@ 2009-05-29 16:17 Tom Lane <tgl@sss.pgh.pa.us>
parent: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
0 siblings, 0 replies; 10+ messages in thread
From: Tom Lane @ 2009-05-29 16:17 UTC (permalink / raw)
To: Zdenek Kotala <Zdenek.Kotala@Sun.COM>; +Cc: pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400:
>> The proposed signature change on psql_completion
>> is going to replace a warning on your system with outright failures on
>> other people's.
> I check readline and definition is still same at least from 5.0 version.
> I'm not still understand why it should failure on other systems. I
> looked on revision 1.30 of the file and there is only readline-4.2
> support mentioned. Is readline 4.2 the problem?
[ pokes around... ] Actually I think the reason it's like this is that
very old versions of readline have completion_matches() rather than
rl_completion_matches(), and the former is declared to take char * not
const char *. So it still would compile, you'd just get cast-away-const
warnings. Which is probably okay considering that hardly anyone is
likely to still be using such old readline libs anyway.
We could try experimenting with that after we branch for 8.5. I'm not
eager to fool with it in late beta, as we'd be invalidating any port
testing already done.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2009-05-29 16:17 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-05-28 09:11 Compiler warning cleanup - unitilized const variables, pointer type mismatch Zdenek Kotala <Zdenek.Kotala@Sun.COM>
2009-05-28 11:33 ` Michael Meskes <meskes@postgresql.org>
2009-05-28 11:51 ` Zdenek Kotala <Zdenek.Kotala@Sun.COM>
2009-05-28 12:47 ` Michael Meskes <meskes@postgresql.org>
2009-05-28 14:34 ` Zdenek Kotala <Zdenek.Kotala@Sun.COM>
2009-05-28 15:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-05-29 12:44 ` Zdenek Kotala <Zdenek.Kotala@Sun.COM>
2009-05-28 15:42 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-05-29 12:36 ` Zdenek Kotala <Zdenek.Kotala@Sun.COM>
2009-05-29 16:17 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox