From owner-freebsd-current Sat Feb 1 22:11:16 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D928E37B401; Sat, 1 Feb 2003 22:11:14 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A28443F79; Sat, 1 Feb 2003 22:11:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h126BESJ021044; Sat, 1 Feb 2003 22:11:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h126BEBh021043; Sat, 1 Feb 2003 22:11:14 -0800 (PST) Date: Sat, 1 Feb 2003 22:11:14 -0800 (PST) From: Matthew Dillon Message-Id: <200302020611.h126BEBh021043@apollo.backplane.com> To: Robert Watson Cc: Mark Murray , current@FreeBSD.org Subject: Re: Style fixups for proc.h References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, there is something to be said for trying to avoid userland namespace pollution, but it is still somewhat of a stretch since most userland programs #include standard and system headers before they #include their own, and the includes are typically done before any code. But I see no reason why the underscore methodology would need to be used for kernelland prototypes. C has its problems and we need to live with them, but we shouldn't have to add bogus underscores to prototyped arguments to work around those problems. I'd prefer normally named arguments but if I were given only a choice between underscored named arguments and unnamed arguments, I'd take unnamed arguments hands down. -Matt :Actually, the pattern is that the function prototypes exposed to userspace :are prefixed with '_' to prevent interfering with the application :namespace. The ones exposed only in the kernel don't. I should probably :update the kernel ones as well. This is mostly because of the profound :evils associated with the C preprocessor, which can cause substitutions to :occur in function prototypes (this is often used intentionally). : :For an example of this evil: there appears to be a convention in which we :name structure elements with a prefix, such as m_blah, based on the :structure name. At one point I added "m_flags" to struct mac. When I :included mbuf.h, this became m_hdr.mh_flags, resulting in fairly obtuse :compile errors. Protecting user applications against hard to understand :compile errors is an important part of providing useful include files to :application writers, so avoiding exposing things to the application :namespace where it can be avoided. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message