Re: best practice to handle unused variables depending on macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6 February 2012 16:47, Mathieu Lacage wrote:
>
> Some of my collegues have started to add #ifdefs here and there in our
> main code to handle these problems as they come. Others have been
> advocating the use of macros that mark the problematic variables as
> unused.

That would be my choice:

int __attribute__((unused)) var =
some_function_whose_return_value_is_used_only_by_assert_macro();


> I considered adding -Wno-unused-variables but feel uneasy about it
> because it is sometimes useful. I toyed with the idea of defining
> NS_ASSERT_MSG differently:
>
> #ifdef USE_NS_ASSERT
> #define NS_ASSERT_MSG(a,b)
> do {
>  if ((a)) {
>    // do stuff with b
>  }
> } while (false)
> #else
> do {
>  if ((a)) {
>    // do nothing with b
>  }
> } while (false)
> #endif
>
> Which would avoid this kind of warning but introduces two new
> problems: developers are used to think that the code in NS_ASSERT_MSG
> is not executed at runtime for optimized builds: this is hard to
> guarantee because the assert statement could invoke arbitrary
> functions located in arbitrary compilation units and the compiler
> can't tell that the function has no side-effects. The other problem,
> of course, happens _if_ the function has side-effects. Arguably, that
> is a bug in the function being called within an assert but, life being
> what it is, this is not something I feel comfortable ruling out. It
> will/does likely happen.

I can't think of a worse solution!

You could define the assert macro to do (void)sizeof(a) which would
not evaluate the expression but which does count as "using" variables
in the expression with current GCC (though don't assume GCC won't get
smarter and warn about it in future)



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux