From owner-freebsd-arch Wed Nov 29 12: 7:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alive.znep.com (sense-sea-MegaSub-1-500.oz.net [216.39.145.246]) by hub.freebsd.org (Postfix) with ESMTP id 119EB37B400 for ; Wed, 29 Nov 2000 12:07:31 -0800 (PST) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.1) with ESMTP id MAA74914; Wed, 29 Nov 2000 12:03:40 -0800 (PST) (envelope-from marcs@znep.com) Date: Wed, 29 Nov 2000 12:03:40 -0800 (PST) From: Marc Slemko To: Marcel Moolenaar Cc: Daniel Eischen , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Modifying FILE to add lock In-Reply-To: <3A255D8A.7F5CFB26@cup.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 Nov 2000, Marcel Moolenaar wrote: > Anyway: In stdio.h I'm told that I should read the warning before > changing the layout of struct __sFILE. There doesn't seem to be a > warning anywhere in the header file, so I figure it must be the long Look in an older revision (eg. 1.1) and you will see a few comments earlier some alignment warnings that have since gone the way of the dodo, sortof. I think that is what it is referring to... > comment before the struct declaration. The comment doesn't tell me what > happens if I change the layout. It only tells me what certain fields are > for and doesn't mention _offset at all, even though that field > specifically references the warning. > > My point: We're hinted to be careful and cautious without actually being > told why. Can someone tell me what problems we might expect if we add a > new field, both specifically at the end and randomly within the > structure? If you add a new field in the middle, then any programs compiled against the old header file that have to access anything in the struct after your addition will potentially fall over horribly since a lot of the access to random fields is done with macros. If you add a field at the end, then anything that allocates memory for a FILE will break, although it is bogus to do that anyway. There is a reason why Solaris was stuck with the lame 8-bit limit on the size of the file descriptor behind a stream for so long, until they changed stuff around anyway in a new (at the time) 64-bit ABI and bumped it up there to a sane number... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message