Date: Thu, 28 Jan 1999 05:12:24 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: nate@mt.sri.com (Nate Williams) Cc: dillon@apollo.backplane.com, nate@mt.sri.com, archie@whistle.com, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG Subject: Re: btokup() macro in sys/malloc.h Message-ID: <199901281012.FAA10811@hda.hda.com> In-Reply-To: <199901280629.XAA26798@mt.sri.com> from Nate Williams at "Jan 27, 99 11:29:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> A warning is just that. It's not an error, so don't treat it like one. I use different productions to enable different warnings on code with different histories. For one thing, new revs of the compiler will otherwise cause trouble when the warning behavior changes. I also use -Werror. Eliminating warnings is almost pointless without this. And yeah, I have a NO_WERROR flag for when I'm in a rush. I know -Werror is the eventual goal. So I disagree with Nate about ignoring warnings you've enabled - it is too easy to ignore a new problem. I agree with him that gratuitous casts and similar fixes during damn-the-torpedos mass conversions of large bodies of code are bad in that they can effectively hide latent problems more deeply than they were hidden before such a conversion. So IMHO: Eliminating warnings is good; Any mechanistic change to eliminate warnings that can mask problems can not be used. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval 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?199901281012.FAA10811>