Subject: Re: bin/7249
To: NetBSD Kernel Technical Discussion List <firstname.lastname@example.org>
From: Greywolf <email@example.com>
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 <firstname.lastname@example.org>
# Reply-To: NetBSD Kernel Technical Discussion List <email@example.com>
# To: NetBSD Kernel Technical Discussion List <firstname.lastname@example.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.
BSD is much like a tipi: No windows, no gates, and an apache inside.