Hi Cyril, On Sun, Dec 15, 2013 at 10:39:56PM +0100, Cyril Bonté wrote: > Hi Willy, > > Le 13/12/2013 10:45, Willy Tarreau a écrit : > >Hi Igor, > > > >On Fri, Dec 13, 2013 at 05:13:51PM +0800, Igor wrote: > >>Hi, Willy, the patch fixed the reported warning, > > > >Thanks for testing! I'm merging it then. > > > >>but seems introduce new warning, the log: http://pastebin.com/dBfHGV2S > > > >No it's not the same. Gcc is getting *really* annoying. It reports stupid > >warnings all the time and forces you to write your code a certain way to > >shut them down. It's really unbelievable. Have you seen the comment in the > >code? It already says that this ugly construct was made *only* to shut gcc > >down. But it seems that your new version is even smarter and now requires > >the semi-colon to be put on a distinct line. It does not make any sense > >any more, this compiler decides on the *form* of your code, not the > >semantics. > >One day we'll see "Warning, you used parenthesis in sizeof which is an > >operator > >and not a function" or "your 'if' statement was indented with spaces > >instead of > >tabs, which might confuse readers with tab size different from 8". > > > >I think that gcc is more and more developped by monkeys for monkeys. > > > >Each version is slower and buggier than the previous one, and more annoying > >on legacy code. > > > >I don't want to put the -Wno-xxxxx flags in the default build options > >because > >some older compilers available on certain platforms don't support them all. > >At the moment haproxy builds back to gcc 2.95. We can decide to support 3.x > >and above in the future but that does not mean we'll gain more options to > >silence it. > > > >That said, if someone is willing to enumerate the list of -Wno-xxx options > >that are supported from 2.95 to 4.8 and which allow us to live in peace > >with this boring compiler, I'm totally open to add them. > > This is not necessarily a gcc issue. From what I see, the older code > > write(1, trash.str, trash.len); > > doesn't produce any warning here (tested on Debian Wheezy/gcc 4.7.2/libc > 2.13 and clang 3.0, Ubuntu 13.10/gcc 4.8.1/libc 2.17 and current Ubuntu > development branch/gcc 4.8.2/libc d.17). > > From the glibc include files, write() is declared as is : > extern ssize_t write (int __fd, __const void *__buf, size_t __n) __wur; > > __wur is what can produce the warning...or not. > It sets the function attribute __attribute_warn_unused_result__ *only* > if _FORTIFY_SOURCE is greater than 0 and (Optimization level is greater > than 0 too). > > _FORTIFY_SOURCE=2 looks to become the default for distribution > packagers. Maybe we could decide to enforce _FORTIFY_SOURCE to 0 in the > Makefile.
To be exact, I know that it's the includes which indicate what syscall need to be checked, but what's really scary is that gcc suggests to put the semi-colon on a different line ! I mean, in C, spaces have zero meaning, and now we start seeing warnings related to the position of spaces only. *that* is becoming scary. Anyway I have fixed the issue based on an idea from Emeric consisting in draining all these unused return values into a global variable which holds a nice name... Cheers, Willy
