Greg - I agree with your sentiments.... I attempted to cover the arguments from both sides of the issue in the code comment. I thought about including url's but there is no guarantee the pages I used would stay around for the forseeable future.
I am also not a fan of -Wno-blah-blah in this case because it would cover up new coding mistakes which is the against the goal of finding problems with -Wall and -Werror. I'm also not terribly interested in figuring out how to properly error handle the dump code either, but someone might be hence I didn't use macro's because I wanted the issue to be highlighted while at the same time it is worked around. That way someone who comes along can see it and decide if they want to use their time to fix it. As for what is the debian thought on the matter? I wouldn't know. Their response would probably be that is a maintainership issue not a packaging issue. I only pointed out for the commit message the how it was uncovered, we are moving to a newer version of debian packaging at cumulus here and the build system uses a newer version of the gcc compiler which produces more warnings than older versions. We also turn on -Werror as that we do not believe that we should be ignoring warnings. These and some other warnings were now causing compilation failures. donald On Sun, Oct 11, 2015 at 10:31 PM, Greg Troxel <[email protected]> wrote: > > [I have been distracted by Things Other Than Quagga and am way behind on > quagga-dev mail. I happened to look at a few messages that seemed like > I could actually reply to.] > > > Donald Sharp <[email protected]> writes: > > > +/* > > + * write_wrapper > > + * > > + * glibc has declared that the return value from write *must* not be > > + * ignored. > > + * gcc see's this problem and issues a warning for the line. > > + * > > + * Why is this a big deal you say? Because both of them are right > > + * and if you have -Werror enabled then all calls to write > > + * generate a build error and the build stops. > > + * > > + * clang has helpfully allowed this construct: > > + * (void)write(...) > > + * to tell the compiler yeah I know it has a return value > > + * I don't care about it at this time. > > + * gcc doesn't have this ability. > > + * > > + * This code was written such that it didn't care about the > > + * return value from write. At this time do I want > > + * to go through and fix and test this code for correctness. > > + * So just wrapper the bad behavior and move on. > > + */ > > +static void write_wrapper (int fd, const void *buf, size_t count) > > +{ > > + if (write (fd, buf, count) <= 0) > > + return; > > + > > + return; > > +} > > This feels like catering to broken warnings, vs fixing something that is > really wrong. Why doesn't casting write to void (if we really do mean > to ignore the return value) work with the gcc in Debian Jessie? Isn't > that a bug in gcc? What does C99 say? > > Couldn't configure add a -Wno-blah-blah to disable just this warning, if > it detects gcc? > > This gcc behavior seems like it will be breaking vast amounts of legit > code. How long has this been going on? What's the reaction in the > debian/gcc lists about it? > > > It also seems like this kind of workaround could be done as a macro, to > avoid changing the source in many places. > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
