Date: Tue, 15 Dec 1998 13:01:20 +0100 From: Eivind Eklund <eivind@yes.no> To: Mike Smith <mike@smith.net.au> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa labpc.c Message-ID: <19981215130120.F46780@follo.net> In-Reply-To: <199812150420.UAA02573@dingo.cdrom.com>; from Mike Smith on Mon, Dec 14, 1998 at 08:20:01PM -0800 References: <19981215045111.B46780@follo.net> <199812150420.UAA02573@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 14, 1998 at 08:20:01PM -0800, Mike Smith wrote: > > 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. > > Examples? I've seen things run on IA with this; I think that only has been to attempt to remove non-compliance, though. I know there have been other systems with non-all-bits-zero NULL pointers, but not that many recently - too much broken code out there. > > 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. > > ANSI C is too restrictive. So, where is the other doc? Note that most of the things that people do that break ANSI C are not necessary. They may save a line of code or a couple of parentheses, but that's it. > > Oh, the ones our compiler have to support because they're used all of > > 10 or so places in the kernel? > > They're used to avoid the assumption that bzero gives zero values (and > to avoid the overhead of calling it when you just want to set some of > the structure). ANSI C guarantees that the structure is initialized as if each field had been set equal to 0, for the correct context 0 for that field (ie, NULL-pointer for pointers, zero for floating point, etc). > > (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.) > > Sounds like you need better verifiers, or at least ones with extendable > syntaxes. I have ones with extendable syntaxes - and I can get all of them to shut up about this easily enough. I just don't want to - I prefer to be alerted to the cases where people get sucked in by the GCC monopoly and RMS 'embrace and extend' techniques (which he started using long before Microsoft). The comment was meant to indicate that I know how many places they are used, and I'm not basing this on some weird gut feeling. > Short of implementing a generalised constructor/destructor mechanism > for structures, either bzero or field initialisers are kinda > unavoidable. I'd prefer bzero() to named field initializers - it will make it impossible to port to anything with a non-all-bits-zero NULL pointer, but I prefer this to not being able to switch compilers. I'd really like more choice in compilers - there are aspects of GCC I strongly dislike. > Of course now you're going to tell me that your checkers don't like > implicit structure copies... I think I can get some of them to dislike it (though they view it as OK now) - do you want me to? ;-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981215130120.F46780>