Subject: Re: bin/7249
To: NetBSD Kernel Technical Discussion List <>
From: Greywolf <>
List: tech-kern
Date: 07/20/2000 18:01:22
On Thu, 20 Jul 2000, Greg A. Woods wrote:

# Date: Thu, 20 Jul 2000 20:07:27 -0400 (EDT)
# From: Greg A. Woods <>
# Reply-To: NetBSD Kernel Technical Discussion List <>
# To: NetBSD Kernel Technical Discussion List <>
# 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.

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