This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: net/bsd_tcp code conditional on (__NetBSD__ || __OpenBSD__)


On Wed, 7 Mar 2012, Grant Edwards wrote:

> On 2012-03-07, Sergei Gavrikov wrote:
> > On Wed, 7 Mar 2012, Grant Edwards wrote:
> >
> >> I'm still working on clean up compiler warnings generated by gcc
> >> 4.6, and all that's left is stuff under net/bsd_tcpip.  There are
> >> variables that are set in code that's compiled unconditionally, but
> >> only referenced in code that's conditional on 
> >> 
> >>   #if defined(__NetBSD__) || defined(__OpenBSD__)
> >
> > Would it possible "hide" those variables by the same condition?
> >
> > Oops, grep shows there are _too many_ such conditional checks. So,
> > it is hard job
> 
> Exactly.  Some of those variables are set in several places, and
> making all of them conditional would get messy.
> 
> >> Does eCos ever build that code with either __NetBSD__ or
> >> __OpenBSD__ defined?
> >
> > and no way to test fixes then.
> >
> >> If not, just removing the variables would seem to be cleaner than
> >> marking them with the "unused" attribute.  [My guess is that the
> >> compiler generates the same code either way, but I haven't verified
> >> that.]
> >
> > I would avoid removing those variables even they are referred from
> > the "died" blocks.
> 
> What I've done so far is that variables that are referenced by
> conditionally compiled code are left in and declared with
> CYGBLD_ATTRIB_UNUSED.   For examples, see
> 
>    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001525
 
Grant, I saw it, but too late, when you start commit the clean-ups.
Great work, thank you!

> >> However, removing the variables rather than marking them unused will
> >> probably mean a lot more work when it comes time to incorporate
> >> updates from upstream (which we all hope will happen someday when
> >> "somebody else" has time to work on it).
> >> 
> >> So: remove or mark as "unused"?
> >
> > And may be leave all such places (=warnings) *as is* by that reason you
> > pointed out?  What's about to enter a temporary suppression using the
> > GCC diagnostic pragma  for net/bcd_tcp code?  (not tested, just an idea)
> >
> >   #pragma GCC diagnostic ignored "-Wunused-but-set-variable"
> 
> Personally, I prefer to do that on a per-variable basis so that the
> warning is still enabled for other variables and will still catch a
> "real" bug should one be introduced.

I fully agreed. To be clear, I talk about BSD TCP/IP code only. We
should have full control for unused-but-set variables for every eCos
package like infra, hal, kernel, kernel tests, RedBoot, etc., but,
IMHO, net/bsd_tcpip code is some exception, it is almost academic code
today and we should do the same things for this package very carefully.
As you said above, removing the variables would "break" *BSD sources.

Just wondering what is a score (wc -l) for such warnings now? I mean
for bsd_tcpip with ipv6 code included?

Sergei

> >   http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
> >
> > Perhaps, that should be included with a check for GCC 4.X version.
> >
> > So: remove, mark as "unused", or leave as is?
> 
> -- 
> Grant Edwards               grant.b.edwards        Yow! I want EARS!  I want
>                                   at               two ROUND BLACK EARS
>                               gmail.com            to make me feel warm
>                                                    'n secure!!
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]