On Tue, Oct 29, 2013 at 7:11 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > Jeffrey Walton wrote: >>> unfixable warnings for most network code due to macro expansion. See: >>> > >>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488884 >>> > >>> > The pattern explained in that bug is still present in the current glibc >>> > headers. >> Well, you can do one of three things. You can allow the defective code >> to thrive, you can fix the defective code ... > > That particular problem appeares to be fixed in current glibc. > On Ubuntu 13.10: > > $ cat htnos.cpp > #include <netinet/in.h> > #include <arpa/inet.h> > > void test( int port ) > { > struct sockaddr_in sa; > sa.sin_port = htons( (uint16_t)port ); // << Warning here in optimized mode > } > $ g++ -Wconversion -c htnos.cpp > [no output] > >> bitops.h is banned from my code bases > > bitops.h is not something provided by Autoconf or by > glibc, so I'm not sure what this (or the rest of your > email) is about. That was about omitting warnings because the they create too much noise. Worse, a lot of that junk is coming from l33t coders who should know better (how many times has glibc or the Linux kernel made Bugtraq or Full Disclosure???).
The defective code needs to be fixed or banned. Turning the waring off because its inconvenient is putting the gun to the head and pulling the trigger. Clearly you favor the use of functions > like strcpy_s, but it's not just Ulrich Drepper who's > skeptical of that sort of approach; see, for example > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt>. Yes, I've read them too. The baby was thrown out with the bath water. Jeff _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
