From owner-freebsd-arch Wed Jan 30 0: 4:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C615237B400 for ; Wed, 30 Jan 2002 00:04:35 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0U84Yo28210; Wed, 30 Jan 2002 01:04:34 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0U84Xx22551; Wed, 30 Jan 2002 01:04:33 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 30 Jan 2002 01:04:16 -0700 (MST) Message-Id: <20020130.010416.109979400.imp@village.org> To: deatley@apple.com Cc: arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Dallas De Atley writes: : My question was: What is the __P macro used for in all those : function declarations in the BSD libraries and do we still need it? It is there for K&R support for the most part. Although there may be some sneaky uses of it that may make it a little difficult to blindly remove. : Is the __P macro still necessary? No. : Are there pre ANSI C compilers : FreeBSD wishes to support or is this macro effectively benign but : useless? Not really. There are a few in the FreeBSD community that would like to continue to support this. However, even they admit that removing uses of the __P macro in the tree would be a good thing. However, there are several caveats: 1) Wholesale removal of this macro would likely cause merge conflicts to those using the p4 repository and who are otherwise maintaining separate projects. Since these are the cool new projects, it is widely believed that some level of coordination is needed with these products. This is especially true in the kernel. 2) There are style(9) concerns about naive removal methods, and a few other asthetic considerations as well. 3) There are concerns about how easy/hard it will be to merge changes after we do this to prior branches. The last time this came up in any real way, the folks with the pitchforks and pitch-oil that wanted to get rid of the thing were placated by the promise that it would be done as part of the glide path to the 5.0 release. I'm not sure which side of the release it will be done on, but I think the thought was before the 5.x-stable branch is created so that while we're working on 6.0 we can MFC changes to the 5.x-branch. This makes it hard on the 4.x branch, but less hard than if we had to do both 5.x and 4.x __P twingling. But I'm not sure that there is an appointed executioner, or an exact timetable for this change to take place. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message