No problem Ed. Hope you enjoyed your vacation.
The code changes are pretty straightforward. I left
them in the style consistent with the rest of the code.
(Using "int"s instead of "bool"s for example.)

I have made the changes suggested by Alexander Ziaee to the
man pages, although I cannot update the diff here.

Ed, maybe you can take a look at the source changes?
The man page changes have already been reviewed.
I can update those and I am willing to commit these
once you've taken a look at them.

If you are agreeable to my version of the length formula,
I will update the patch with that and checks for NULL
return for both strdup() and malloc().

I did take a quick look at the Linux code and it
appears to be completely different to me, so I
don't think trying to convert it makes sense, at
least for now.

Used strdup() to copy the options into a malloc'd area,
as suggested by mav@. This makes sense, since a sharenfs
with many semicolons could be much larger than an
option list.

This version ignores whitespace only semicolon separated
option sets. I decided that allowing the "only whitespace
case" which generates a line with default options (which
is read/write to the world) did not make sense when other
option sets are being specified for other hosts/networks.

I've made some inline comments, but it looks generally ok to me.
All the man page updates require a change to the date (.Dd line)
and manpages should be asked for a group review.

I believe so, yes.

Made the changes suggested by kib@.

In D44906#1023894, @olce wrote:

In D44906#1023893, @markj wrote:

Oh hmm, not unrelated, but at a glance I think it is superseded by the privport check. That is, all code paths which lead there first have to go through the privport check. But I could be wrong about this.

It feels like NFS_REQRSVPORT is older but apparently it was introduced by the same (initial) commit as the if (nfs_privport ... check (9ec7b004d0edb). Maybe replacing NFS_REQRSVPORT by a runtime check for nfs_privport would make sense, but I don't really know this code. It may be instead that the code under NFS_REQRSVPORT is redundant, I'm not sure either. In any case, this would be a separate change.

lgtm. I cannot recall if there is any man page change
needed for this?

markj@ has a better patch in D44614.

I made a couple of comments, but feel free to ignore
them, since I think the patch is fine without the changes.

In D44499#1015512, @markj wrote:

I'd somewhat prefer to make this more prominent, having its own paragraph in the description section. I understand that the problem at hand is a natural consequence of how exports(5) works, but it's really easy for someone new to NFS to miss that they can't "safely" export a single subdirectory from a local filesystem on the server.

Made the changes suggested by emaste@.

This version looks fine to me. I'll let you decide whether or
not to leave the TCP check in.