From owner-freebsd-hackers Thu Feb 18 6:35:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C4A6011552 for ; Thu, 18 Feb 1999 06:35:46 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA97124; Thu, 18 Feb 1999 15:32:18 +0100 (CET) (envelope-from des) To: perlsta Cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: From: Dag-Erling Smorgrav Date: 18 Feb 1999 15:32:17 +0100 In-Reply-To: perlsta's message of "Tue, 16 Feb 1999 12:49:59 -0500 (EST)" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG perlsta writes: > > > > > the C spec says that the BSS contains zeroes, so it's > > > > > typically assumed that all unitialised globals will be zeroed. > > If this is something that can be relied upon, why add implicit zero's in the > > code? > because lazy coders have depended on that feature for years now, and > changing it would break too many things. not only that but it's nice to > know that _some_ things will be zero'd out for you. If you have a *lot* of global data in your app, you basically have a choice between a) initializing them in main(), b) spending some CPU cycles zeroing the BSS at load time, or c) initializing them explicitly in the source code, which will move them into DATA and eat up disk space. Kind of stupid to waste disk space on a lot of zeroes. That leaves you with a) and b), and b) makes it easier on the programmer (though personally I wouldn't consider a) a big nuisance) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message