Closed Bug 187530 Opened 23 years ago Closed 22 years ago

Need a canonical way of declaring varibles that are only used for debugging.

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mozilla-bugs, Assigned: asa)

References

(Blocks 1 open bug)

Details

Im many places Mozilla has code of the form nsresult rv = ...; NS_ASSERT(NS_SUCCEEDED(rv), ...); which means that in an --disable-debug build we end up getting a warning about rv being unused (of course, this is happens not only with nsresults, I am just using an nsresult as an example). It would be nice to have some "canonical" way of dealing with this. One way could be to define a macro like #ifdef DEBUG #define DEBUG_ONLY(x) x #else #define DEBUG_ONLY(x) #endif and turn the code above into DEBUG_ONLY(nsresult rv =) ...; NS_ASSERT(NS_SUCCEEDED(rv), ...); Another solution would be to do what bug 68036 did and to explicitly use #ifdef DEBUG nsresult rv = #endif ... NS_ASSERT(NS_SUCCEEDED(rv), ...); but IMHO this is just too ugly. What do you think?
This would be best brought up in n.p.m.reviewers, where people who actually have useful opinions on this stuff (super-reviewers) will see it....
The intent of this bug was also toserve as a request for a DEBUG_ONLY (or similar) macro to be actially added to some common header file. But you are probably right and I've just posted this question to n.p.m.revievers.
Another option, consider a variation of NS_ASSERTION that is defined as if (x) {} for release builds. I would hope most compilers would at worse allocate the rv and not even bother generating the code of the test. At best, optimize it out all together. Have to weigh the added complexity created by a variant of NS_ASSERTION over getting rid of such warnings.
Actually maybe a better option is to create a variant that evaluates to the expresion for release. Then you'd just do: NS_THEMACRO(function(x)); Forget defining the variable all together.
I recently approached brendan and alecf with this idea, and was gently discouraged from checking it in. The consensus was to live with warnings in the optimized build rather than add such a macro or clutter debug variable declarations with #ifdef's. Asa, perhaps you can mark this WONTFIX, or try convincing brendan yourself.
And... I tried it Mozilla 1.4 on Debian Linux with JRE1.4.1 Works here. The debian system did not even have the weird visual glitch.
Not sure the comment was meant for this bug. Seems the general consensus is/was WONTFIX so marking it as such.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.