Date: Fri, 13 Jun 2003 09:43:56 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Moran <wmoran@potentialtech.com> Cc: fcash@sd73.bc.ca Subject: Re: Looking for holes in the docs to fill in Message-ID: <3EE9FF4C.EB3630C@mindspring.com> References: <3EE8C1F4.7000800@potentialtech.com> <3EE9D11C.1040008@potentialtech.com> <3EE9F282.4020806@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If anyone in this thread is still interested, there's actually a pretty big job to do in the documentation department, but it's more real technical writing, as it involves looking at code. Specifically, it would be nice to go through the manual pages relative to the implementation, and make sure that they correspond. But that's not all. It would be useful to go through the online SuSv3 manual pages, and effectively make the manual pages correspond (they can't be identical for the usual copyright reasons, so this requires creativitiy). Then add two sections to each page: "DEVIATIONS FROM THE STANDARD" and "BSD EXTENSIONS". This would make it *very* clear to program writers what they should be using to get standards compliant programs, and what cross-platform behaviours they should and should not expect, and what local extensions are available, if you know that you prefer performance (or BSD legacy with potential performance loss!) over portability. Personally, I would also refer them to a "bsd_extensions" man page as well, and that page would suggest strongly that any code that was written using a BSD extension wrapper it with appropriate #ifdef's, for portability's sake. The manifest constant to use is up to whoever, but "BSD_VISIBLE" and "FREEBSD" are likely candidates (with whatever underscores they have this week). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EE9FF4C.EB3630C>