On Tue, Oct 29, 2013 at 7:55 PM, Paul Eggert <eggert@xxxxxxxxxxx> wrote: > Jeffrey Walton wrote: >> Turning the waring off >> because its inconvenient > > It's not merely that the warning's inconvenient. It's that > it's simply wrong, as shown in the example I gave earlier > <http://lists.gnu.org/archive/html/autoconf/2013-10/msg00030.html>. Well, I can't duplicate it on Ubuntu 12.04 either, so its hard to say how I would handle it. But a few thoughts.... First, time_t is supposed to be an integer or real (http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html). Its hard to blame the compiler's warning system for a broken implementation. Second, use of the unsigned time_t probably kept that math well defined (overflow on signed integers is definitely undefined). Its not the first time we've been screwed with a standard. Third, the Linux kernel guys don't feel the C language rules apply to them. In general, avoid their stuff. Its not heresy - have you seen how often they make appearances on Bugtraq and Full Disclosure from basic errors? Dan Rosenberg makes a career out of these silly mistakes. And some of its not clever at all - its the stuff that would flunk you out of a ComSci 101 program. Fourth, shit happens and you have to learn to work around it. > Requiring programmers to rewrite their code to avoid bogus warnings > makes bugs more likely, not less. Well, I agree that we should not have to do it. However, its a different story in practice.... I think part of the "art of programming" is learning to work with these quirks. Quirks include irregularities in he language, the tools, and even bad standard implementations (like the kernel or glibc). Otherwise, you throw the baby out with the bath water again. I recently looked at code that used NetBSD's UUID parser for MAC addresses. eui64.c was copied/pasted into a project, and it triggered under -Wconversion. I was able to write 15 or so negative test cases that broke that parser based on that one warning. Throwing the baby out with the bath water was a bad idea. Jeff _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
