Looking for holes in the docs to fill in

[Terry Lambert]

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