From owner-cvs-all Mon Dec 14 19:51:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04004 for cvs-all-outgoing; Mon, 14 Dec 1998 19:51:20 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03996; Mon, 14 Dec 1998 19:51:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id EAA23268; Tue, 15 Dec 1998 04:51:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA46819; Tue, 15 Dec 1998 04:51:11 +0100 (MET) Message-ID: <19981215045111.B46780@follo.net> Date: Tue, 15 Dec 1998 04:51:11 +0100 From: Eivind Eklund To: Mike Smith Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa labpc.c References: <199812132325.PAA16418@freefall.freebsd.org> <199812150119.RAA01309@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812150119.RAA01309@dingo.cdrom.com>; from Mike Smith on Mon, Dec 14, 1998 at 05:19:28PM -0800 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Mon, Dec 14, 1998 at 05:19:28PM -0800, Mike Smith wrote: > > eivind 1998/12/13 15:25:29 PST > > > > Modified files: > > sys/i386/isa labpc.c > > Log: > > Fix typo - sizeof(struct crtl *) -> sizeof(struct ctrl *). > > > > XXX This still assume that bzero() over a field create null-pointers, > > which seems a chancy proposition at best. > > This is assumed by many portions of the kernel; you're welcome to point > out a system where we're likely to run and on which this isn't a valid > assumption. We could e.g. want to run on segmented setup with NULL-pointers not equal to bitwise zero. However, if we are to assume that NULL pointers are all-bits-zero - where would we document this? Is there _any_ available document saying which assumptions we make WRT portability? If there isn't and nobody step forward to make one, I'm going to keep using ANSI C as my goal, and consider it a Bad Thing whenever something break it. > You might also want to consider it in the context of my last comment > about structure field initialisers... Oh, the ones our compiler have to support because they're used all of 10 or so places in the kernel? (I've run verifiers that _screams_ when these are used and gone through all their output over the last week - we don't have that many parts where structure field initializers or union initializers are used, though the abuse in sys/dev/ppbus/ and sys/i386/i386/userconfig.c does pull up the instance-count pretty heftily.) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message