I'd actually recommend running FLTK through Clang's (new) C++ static analyzer,
but regardless an unused assignment is an unnecessary one.
The unused return value warnings can be silenced with "(void)" in front of the
call, if desired...
FYI, the Clang-based static analyzer lives here:
http://clang-analyzer.llvm.org/
Binaries are provided for Mac OS X, and it is actually pretty easy to build on
Linux, too.
On Oct 18, 2011, at 4:49 AM, Albrecht Schlosser wrote:
> Hi (sigh),
>
> there are new warnings generated by gcc 4.6.1 (latest MinGW gcc
> version, released Sep 15, 2011) about unused, but set variables,
> e.g.:
>
> Compiling Fl_Browser.cxx...
> Fl_Browser.cxx: In member function 'virtual int
> Fl_Browser::item_height(void*) const':
> Fl_Browser.cxx:375:14: warning: variable 'dummy' set but not used
> [-Wunused-but-set-variable]
>
> (2 more warnings in the same file, and a few more elsewhere).
>
> The problem with these warnings is that we (Matt) *introduced* some
> dummy variables (in svn r 7765) to silence other warnings (the
> following is from FLTK 1.1 that doesn't have this change (on
> Linux, gcc 4.4.4):
>
> Compiling Fl_Browser.cxx...
> Fl_Browser.cxx: In member function ?virtual int
> Fl_Browser::item_height(void*) const?:
> Fl_Browser.cxx:236: warning: ignoring return value of ?long int
> strtol(const char*, char**, int)?, declared with attribute
> warn_unused_result
>
> The same applies to some other similar warnings, e.g. for fwrite().
>
>
> So, what to do to silence the new warnings? I tried two solutions
> that both made the warnings go away, but both appear to be hacks,
> and they are confusing (w/o an appropriate comment):
>
> Possible solutions: add one of these two lines to reference the
> dummy variable:
>
> if (dummy); // silence gcc warning [-Wunused-but-set-variable]
> dummy++; // silence gcc warning [-Wunused-but-set-variable]
>
> Both statements could easily be optimized away by the compiler,
> but the 2nd would have a side effect (if not removed, if the
> variable were used elsewhere in a later version). So I'd tend
> to use the former...
>
> Are there any better ideas (except disabling the warnings?).
>
> Should I go ahead and add such silly statements?
>
> Dev's (and others), what do you think?
>
> Albrecht
> _______________________________________________
> fltk-dev mailing list
> [email protected]
> http://lists.easysw.com/mailman/listinfo/fltk-dev
_____________
Michael Sweet
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
