Date: Wed, 27 Jan 1999 23:29:37 -0700 From: Nate Williams <nate@mt.sri.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@mt.sri.com>, Archie Cobbs <archie@whistle.com>, wollman@khavrinen.lcs.mit.edu (Garrett Wollman), current@FreeBSD.ORG Subject: Re: btokup() macro in sys/malloc.h Message-ID: <199901280629.XAA26798@mt.sri.com> In-Reply-To: <199901280603.WAA93627@apollo.backplane.com> References: <199901280222.VAA14212@khavrinen.lcs.mit.edu> <199901280229.SAA20207@bubba.whistle.com> <199901280540.WAA26288@mt.sri.com> <199901280603.WAA93627@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :> then we need to update sytle(9) to reflect that. > :> > :> In fact, style(9) should say: > :> > :> If at all possible, your code should compile without warnings > :> when the gcc -Wall flag is given. > : > :I disagree. As has been shown many times in the past (and I suspect the > :down-under constituent will show that at least a couple of the > :'warnings' fixes will be wrong and hide bogus code), making -Wall a goal > :causes people to cover up bad code with bad casts and such. > : > :'-Wall' is *NOT* a good design goal. > > Nonsense. -Wall does *NOT* contribute to a bad programmer programming > badly, and I found at least three fairly serious mistakes when I turned > it on. And introduced at least one. If you were a programmer under my charge, I'd tell you to use the warnings to fix only those bugs you are sure of and leave the others alone. > I mean, come on... by your argument the compiler might as well give up > and not bother warning you about anything! A warning is just that. It's not an error, so don't treat it like one. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901280629.XAA26798>