[PATCH] uemis-downloader.c: fix some read() and write() warnings

Dirk Hohndel dirk at hohndel.org
Wed Oct 9 07:36:37 UTC 2013


On Wed, 2013-10-09 at 17:35 +0300, Lubomir I. Ivanov wrote:
> On 9 October 2013 17:27, Dirk Hohndel <dirk at hohndel.org> wrote:
> > On Wed, 2013-10-09 at 17:14 +0300, Lubomir I. Ivanov wrote:
> >> On 9 October 2013 17:10, Dirk Hohndel <dirk at hohndel.org> wrote:
> >> >
> >> > Well, this patch is one of those examples where I think fixing the
> >> > warnings is just stupid. You are just moving the same issue (in this
> >> > code I really don't care about the result of read) to a different spot
> >> > where the compiler doesn't notice. You now have all these ret variables
> >> > that get set and then ignored. There is another warning that we could
> >> > turn on that will then complain about that :-)
> >> >
> >>
> >> perhaps we should add "-Wno-unused-result" then.
> >
> > But WHY? If I don't need the result of the read, I don't need the
> > compiler spewing warnings.
> >
> > There are about 40 warnings about possibly uninitialized variables. Yes,
> > we could work around all those and make the compiler happy, but the
> > reality is for our scenario this can never happen, so adding default
> > initializations either make the code slower or harder to read or both.
> >
> > I am all for occasionally going through and looking at these warnings -
> > but I'm not a huge fan of then turning around and making the code harder
> > to read in order to silence the compiler.
> >
> > E.g.: a call to read() tells me that I didn't need the result.
> >
> > int ret = read() makes me think that I wanted to do something with it.
> >
> > more code to make the unused result warning go away is worse.
> >
> 
> i think "-Wno-uniused-result" should simply make the warning go away
> and this patch is not needed (i.e. having "int ret = ...").
> if we want these warnings on the other hand for other locations,
> "-Wno-uniused-result" should not be added.

Sorry, you are of course correct. My mistake.

/D



More information about the subsurface mailing list