On Thu, 20 Jul 2000, Greg A. Woods wrote:

# Date: Thu, 20 Jul 2000 20:07:27 -0400 (EDT)
# From: Greg A. Woods <woods@weird.com>
# Reply-To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
# To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
# Subject: Re: bin/7249 
# 
# [ On Thursday, July 20, 2000 at 16:06:46 (-0700), Greywolf wrote: ]
# > Subject: Re: bin/7249 
# >
# > What's wrong with using the .so directive, and perhaps splitting out
# > the definitions into smaller files?  It would solve the problem of duplicity.
# 
# Yeah, but ".so" is a nasty and unportable hack (thus soelim).  Groff
# does implement ".so" internally, and adds ".mso" which would be closer
# to what one would want, but I still feel it is a bad hack.  (There's
# even ".pso"! ;-)

What's hackish about it?  Do you consider #include to be a hack, or a
functional part of the preprocessor?

I guess I don't understand why it is not portable -- is it one of those
not-implemented-everywhere things, or what?

# Besides there's already a link that causes "man errno" to display up
# intro(2).  When you combine this fact with the goal of keeping manual
# pages concise and simple, I think the best compromise is to simply list
# errno values/codes that have their common meaning and to only describe
# in detail those that have unique meanings for the given function.  There
# could be a "SEE ALSO" entry pointing at errno(2) for pedants, I suppose.

Well, it still would have solved the duplicity problem.

				--*greywolf;
--
BSD is much like a tipi:  No windows, no gates, and an apache inside.