Thread: lots of unused variable warnings in assert-free builds
In builds without --enable-cassert (I guess not many developers use those a lot), there are quite a few unused variable warnings. These usually hold some intermediate result that the assert checks later. I see that in some places our code already uses #ifdef USE_ASSERT_CHECKING, presumably to hide similar issues. But in most cases using this would significantly butcher the code. I found that adding __attribute__((unused)) is cleaner. Attached is a patch that cleans up all the warnings I encountered.
Attachment
Peter Eisentraut <peter_e@gmx.net> writes: > I see that in some places our code already uses #ifdef > USE_ASSERT_CHECKING, presumably to hide similar issues. But in most > cases using this would significantly butcher the code. I found that > adding __attribute__((unused)) is cleaner. Attached is a patch that > cleans up all the warnings I encountered. Surely this will fail entirely on most non-gcc compilers? Not to mention that next month's gcc may complain "hey, you used this 'unused' variable". I think #ifdef USE_ASSERT_CHECKING is really the only way if you care about quieting these warnings. (Personally, I don't.) regards, tom lane
On 01/15/2012 01:37 AM, Tom Lane wrote: > Peter Eisentraut<peter_e@gmx.net> writes: >> I see that in some places our code already uses #ifdef >> USE_ASSERT_CHECKING, presumably to hide similar issues. But in most >> cases using this would significantly butcher the code. I found that >> adding __attribute__((unused)) is cleaner. Attached is a patch that >> cleans up all the warnings I encountered. > Surely this will fail entirely on most non-gcc compilers? Not to > mention that next month's gcc may complain "hey, you used this 'unused' > variable". I think #ifdef USE_ASSERT_CHECKING is really the only way > if you care about quieting these warnings. (Personally, I don't.) > > It would possibly have some documentary value too. Just looking very quickly at Peter's patch, I don't really understand his assertion that this would significantly butcher the code. The worst effect would be that in a few cases we'd have to break up multiple declarations where one of the variables was in this class. That doesn't seem like a tragedy. I like software that compiles in the normal use with few or no warnings. I should have thought that would appeal to most packagers, too. cheers andrew
On Sun, Jan 15, 2012 at 1:14 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > > On 01/15/2012 01:37 AM, Tom Lane wrote: >> >> Peter Eisentraut<peter_e@gmx.net> writes: >>> >>> I see that in some places our code already uses #ifdef >>> USE_ASSERT_CHECKING, presumably to hide similar issues. But in most >>> cases using this would significantly butcher the code. I found that >>> adding __attribute__((unused)) is cleaner. Attached is a patch that >>> cleans up all the warnings I encountered. >> >> Surely this will fail entirely on most non-gcc compilers? Not to >> mention that next month's gcc may complain "hey, you used this 'unused' >> variable". I think #ifdef USE_ASSERT_CHECKING is really the only way >> if you care about quieting these warnings. (Personally, I don't.) >> >> > > > > It would possibly have some documentary value too. Just looking very quickly > at Peter's patch, I don't really understand his assertion that this would > significantly butcher the code. The worst effect would be that in a few > cases we'd have to break up multiple declarations where one of the variables > was in this class. That doesn't seem like a tragedy. > > I like software that compiles in the normal use with few or no warnings. I > should have thought that would appeal to most packagers, too. Sounds good, but let's not do it yet because we have a few patches to commit first. It would be good to minimise bit rot during the CF. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I see that in some places our code already uses #ifdef > > USE_ASSERT_CHECKING, presumably to hide similar issues. But in most > > cases using this would significantly butcher the code. I found that > > adding __attribute__((unused)) is cleaner. Attached is a patch that > > cleans up all the warnings I encountered. > > Surely this will fail entirely on most non-gcc compilers? No, because __attribute__() is defined to empty for other compilers. We use this pattern already. > Not to > mention that next month's gcc may complain "hey, you used this 'unused' > variable". No, because __attribute__((unused)) means "that the variable is meant to be possibly unused".
On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote: > It would possibly have some documentary value too. Just looking very > quickly at Peter's patch, I don't really understand his assertion that > this would significantly butcher the code. The worst effect would be > that in a few cases we'd have to break up multiple declarations where > one of the variables was in this class. That doesn't seem like a > tragedy. Well, I'll prepare a patch like that and then you can judge.
Peter Eisentraut <peter_e@gmx.net> writes: > On sön, 2012-01-15 at 01:37 -0500, Tom Lane wrote: >> Surely this will fail entirely on most non-gcc compilers? > No, because __attribute__() is defined to empty for other compilers. We > use this pattern already. Oh, duh. In that case my only objection to doing it like this is that I'd like to see what pgindent will do with it. pgindent is not very nice about #ifdef's in variable lists (it tends to insert unwanted vertical space) so it's possible that this way will look better. regards, tom lane
On ons, 2012-01-18 at 21:16 +0200, Peter Eisentraut wrote: > On sön, 2012-01-15 at 08:14 -0500, Andrew Dunstan wrote: > > It would possibly have some documentary value too. Just looking very > > quickly at Peter's patch, I don't really understand his assertion that > > this would significantly butcher the code. The worst effect would be > > that in a few cases we'd have to break up multiple declarations where > > one of the variables was in this class. That doesn't seem like a > > tragedy. > > Well, I'll prepare a patch like that and then you can judge. So, here are three patches that could solve this issue. pg-cassert-unused-attribute.patch, the one I already showed, using __attribute__((unused). pg-cassert-unused-ifdef.patch, using only additional #ifdef USE_ASSERT_CHECKING. This does have additional documentation value, but you can see that it gets bulky and complicated. (I introduced several bugs merely while creating this patch.) pg-cassert-unused-void.patch is an alternative approach that avoids the warnings by casting the arguments of Assert() to void if assertions are disabled. This has the least code impact, but it changes the traditional semantics of asserts, which is that they disappear completely when not enabled. You can see how this creates a problem in src/backend/replication/syncrep.c, where the nontrivial call to SyncRepQueueIsOrderedByLSN() now becomes visible even in non-assert builds. I played around with some other options like __attribute__((pure)) to make the compiler optimize the function away in that case, but that didn't appear to work. So this might not be a workable solution (and it would be GCC-specific anyway).
Attachment
On Sat, Jan 21, 2012 at 1:06 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > So, here are three patches that could solve this issue. > > pg-cassert-unused-attribute.patch, the one I already showed, using > __attribute__((unused). > > pg-cassert-unused-ifdef.patch, using only additional #ifdef > USE_ASSERT_CHECKING. This does have additional documentation value, but > you can see that it gets bulky and complicated. (I introduced several > bugs merely while creating this patch.) > > pg-cassert-unused-void.patch is an alternative approach that avoids the > warnings by casting the arguments of Assert() to void if assertions are > disabled. This has the least code impact, but it changes the > traditional semantics of asserts, which is that they disappear > completely when not enabled. You can see how this creates a problem in > src/backend/replication/syncrep.c, where the nontrivial call to > SyncRepQueueIsOrderedByLSN() now becomes visible even in non-assert > builds. I played around with some other options like > __attribute__((pure)) to make the compiler optimize the function away in > that case, but that didn't appear to work. So this might not be a > workable solution (and it would be GCC-specific anyway). I think the third approach is unacceptable from a performance point of view. Some of these problems can be fixed without resorting to as much hackery as you have here. For example, in nodeWorkTableScan.c, you could easily fix the problem by getting rid of the estate variable and replacing its single use within the assertion with the expression from used to initialize it on the previous line. I think this might the cleanest solution in general. I'm not sure what to do about the cases where that isn't practical. Spraying the code with __attribute__((unused)) is somewhat undesirable because it could mask a failure to properly initialize the variable in an assert-enabled build. We could have a macro PG_UNUSED_IF_NO_ASSERTS or something, but that doesn't have any obvious advantage over just getting rid of the variable altogether in such cases. I lean toward the view that variables not needed in assertion-free builds should be #ifdef'd out altogether, as in your second patch, but we should try to minimize the number of places where we need to do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > Spraying the code with __attribute__((unused)) is somewhat undesirable > because it could mask a failure to properly initialize the variable in > an assert-enabled build. Ouch. Is it really true that __attribute__((unused)) disables detection of use of uninitialized variables? That would be nasty, and it's not obvious to me why it should need to work like that. But if it is true, then I agree that that makes this approach not too tenable. regards, tom lane
On Tue, Jan 24, 2012 at 12:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Spraying the code with __attribute__((unused)) is somewhat undesirable >> because it could mask a failure to properly initialize the variable in >> an assert-enabled build. > > Ouch. Is it really true that __attribute__((unused)) disables detection > of use of uninitialized variables? That would be nasty, and it's not > obvious to me why it should need to work like that. But if it is true, > then I agree that that makes this approach not too tenable. Oh, I think maybe I am confused. The downsides of disabling *unused* variable detection are obviously much less than the downsides of disabling *uninitialized* variable declaration... although neither is ideal. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jan 24, 2012 at 12:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Ouch. Is it really true that __attribute__((unused)) disables detection >> of use of uninitialized variables? > Oh, I think maybe I am confused. The downsides of disabling *unused* > variable detection are obviously much less than the downsides of > disabling *uninitialized* variable declaration... although neither is > ideal. OK. MHO is that __attribute__((unused)) is probably less annoying than #ifdef overall. Also, it occurs to me that an intermediate macro "PG_USED_FOR_ASSERTS_ONLY" would be a good idea, first because it documents *why* you want to mark the variable as possibly unused, and second because changing the macro definition would provide an easy way to check for totally-unused variables, in case we wanted to periodically make such checks. This is all modulo the question of what pgindent will do with it, which I would still like to see tested before we commit to a method. regards, tom lane
I wrote: > Also, it occurs to me that an intermediate macro > "PG_USED_FOR_ASSERTS_ONLY" would be a good idea, first because it > documents *why* you want to mark the variable as possibly unused, > and second because changing the macro definition would provide an easy way > to check for totally-unused variables, in case we wanted to periodically > make such checks. Uh, wait a second. Why not #ifdef USE_ASSERT_CHECKING #define PG_USED_FOR_ASSERTS_ONLY #else #define PG_USED_FOR_ASSERTS_ONLY __attribute__((unused)) #endif Then, when you build with asserts on, you *automatically* get told if the variable is entirely unused. regards, tom lane
On Tue, Jan 24, 2012 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Also, it occurs to me that an intermediate macro >> "PG_USED_FOR_ASSERTS_ONLY" would be a good idea, first because it >> documents *why* you want to mark the variable as possibly unused, >> and second because changing the macro definition would provide an easy way >> to check for totally-unused variables, in case we wanted to periodically >> make such checks. > > Uh, wait a second. Why not > > #ifdef USE_ASSERT_CHECKING > #define PG_USED_FOR_ASSERTS_ONLY > #else > #define PG_USED_FOR_ASSERTS_ONLY __attribute__((unused)) > #endif > > Then, when you build with asserts on, you *automatically* get told > if the variable is entirely unused. Yes, that's what I meant when I suggested it originally. I'm just not sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > Yes, that's what I meant when I suggested it originally. I'm just not > sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING. I'm inclined to think that it probably is nicer, just because of less vertical space used. But again, this opinion is contingent on what it will look like after pgindent gets done with it ... regards, tom lane
On tis, 2012-01-24 at 13:18 -0500, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Yes, that's what I meant when I suggested it originally. I'm just not > > sure it's any nicer than adding ifdefs for USE_ASSERT_CHECKING. > > I'm inclined to think that it probably is nicer, just because of less > vertical space used. But again, this opinion is contingent on what it > will look like after pgindent gets done with it ... Here is a demo diff of what pgindent would do with the various approaches (btw., nice job on making pgindent easy to use for everyone now). As you can see, pgindent adds whitespace on top of #ifdef USE_ASSERT_CHECKING, and messes up the vertical alignment of variable definitions that contain extra attributes. All things considered, I like the PG_USED_FOR_ASSERTS_ONLY solution best. diff --git i/src/backend/access/hash/hashovfl.c w/src/backend/access/hash/hashovfl.c index 130c296..b61c8ee 100644 --- i/src/backend/access/hash/hashovfl.c +++ w/src/backend/access/hash/hashovfl.c @@ -391,7 +391,10 @@ _hash_freeovflpage(Relation rel, Buffer ovflbuf, uint32 ovflbitno; int32 bitmappage, bitmapbit; + +#ifdef USE_ASSERT_CHECKING Bucket bucket; +#endif /* Get information from the doomed page */ _hash_checkpage(rel, ovflbuf, LH_OVERFLOW_PAGE); @@ -400,7 +403,9 @@ _hash_freeovflpage(Relation rel, Buffer ovflbuf, ovflopaque = (HashPageOpaque) PageGetSpecialPointer(ovflpage); nextblkno = ovflopaque->hasho_nextblkno; prevblkno = ovflopaque->hasho_prevblkno; +#ifdef USE_ASSERT_CHECKING bucket = ovflopaque->hasho_bucket; +#endif /* * Zero the page for debugging's sake; then write and release it. (Note: diff --git i/src/backend/executor/execCurrent.c w/src/backend/executor/execCurrent.c index b07161f..2c8929b 100644 --- i/src/backend/executor/execCurrent.c +++ w/src/backend/executor/execCurrent.c @@ -151,7 +151,7 @@ execCurrentOf(CurrentOfExpr *cexpr, { ScanState *scanstate; bool lisnull; - Oid tuple_tableoid; + Oid tuple_tableoid PG_USED_FOR_ASSERTS_ONLY; ItemPointer tuple_tid; /* diff --git i/src/backend/executor/nodeMaterial.c w/src/backend/executor/nodeMaterial.c index b320b54..3a6bfec 100644 --- i/src/backend/executor/nodeMaterial.c +++ w/src/backend/executor/nodeMaterial.c @@ -66,7 +66,7 @@ ExecMaterial(MaterialState *node) * Allocate a second read pointer to serve as the mark. We know it * must have index 1, so needn't store that. */ - int ptrno; + int ptrno PG_USED_FOR_ASSERTS_ONLY; ptrno = tuplestore_alloc_read_pointer(tuplestorestate, node->eflags); diff --git i/src/backend/executor/nodeSetOp.c w/src/backend/executor/nodeSetOp.c index 7fa5730..ad2e80d 100644 --- i/src/backend/executor/nodeSetOp.c +++ w/src/backend/executor/nodeSetOp.c @@ -344,7 +344,7 @@ setop_fill_hash_table(SetOpState *setopstate) SetOp *node = (SetOp *) setopstate->ps.plan; PlanState *outerPlan; int firstFlag; - bool in_first_rel; + bool in_first_rel __attribute__((unused)); /* * get state info from node diff --git i/src/include/c.h w/src/include/c.h index 82acd14..2dd5c67 100644 --- i/src/include/c.h +++ w/src/include/c.h @@ -850,4 +850,10 @@ extern int fdatasync(int fildes); /* /port compatibility functions */ #include "port.h" +#ifdef USE_ASSERT_CHECKING +#define PG_USED_FOR_ASSERTS_ONLY +#else +#define PG_USED_FOR_ASSERTS_ONLY __attribute__((unused)) +#endif + #endif /* C_H */
Peter Eisentraut <peter_e@gmx.net> writes: > As you can see, pgindent adds whitespace on top of #ifdef > USE_ASSERT_CHECKING, and messes up the vertical alignment of variable > definitions that contain extra attributes. Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable name, which means that the behavior might be more exciting for multi-word type names (for instance "struct foo" or "volatile int *". Could you check a few cases like that? > All things considered, I like the PG_USED_FOR_ASSERTS_ONLY solution best. I agree, unless the more complicated cases go further off the rails. regards, tom lane
On tis, 2012-03-20 at 15:04 -0400, Tom Lane wrote: > Hm. I bet it thinks that PG_USED_FOR_ASSERTS_ONLY is the variable > name, which means that the behavior might be more exciting for > multi-word type names (for instance "struct foo" or "volatile int *". > Could you check a few cases like that? Tested, doesn't make a difference. Hence committed that way.