Date: Sat, 1 Feb 2003 22:11:14 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Mark Murray <mark@grondar.org>, current@FreeBSD.org Subject: Re: Style fixups for proc.h Message-ID: <200302020611.h126BEBh021043@apollo.backplane.com> References: <Pine.NEB.3.96L.1030202003329.63806H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302020611.h126BEBh021043>