Improve wording.

I wonder whether we should increase NL_ARGMAX if we're actually enforcing it, including for strings that do not have n$.

This does not seem wrong, but it is a bit strange to handle this undefined behaviour problem but not the integer overflow when parsing the number in __find_arguments() and __find_warguments() and the integer overflows in __grow_type_table().

I think this is quite nice.

Looks good otherwise.

Perhaps it would be even better to use strdup() instead of fixed-length buffers but for a part of FreeBSD that is not very important. This change in this review is important and fixes a real problem.

A few years ago, a change was made to getdtablesize() so it is no longer equivalent to getrlimit(RLIMIT_NOFILE).rlim_cur: getdtablesize() reflects rctl(8), while getrlimit(RLIMIT_NOFILE) and sysconf(_SC_OPEN_MAX) do not. Therefore, it may be useful to use getdtablesize() if what is desired is as accurate a file descriptor limit as possible.

This change is good but I do not see any follow-up changes.

Looks good to me. Make sure to update .Dd in cron.8 when committing.

It seems a bit strange to refer to close(2) and free(3) from a section 9 (kernel) man page since those functions cannot be called from the kernel. The nv(9) man page already in -current seems to have the same problem. Ideally, the man page would describe the differences between the kernel and userland versions of the APIs.

In D7355#154344, @ed wrote:

After the discussion I started on arch@ regarding symbol versioning naming, I think we'd better just stick to the current approach and go ahead with this specific change as proposed. Ed, Jilles, any more remarks on this change? Let's land this change on August 12th.

Perhaps this is a good first step regarding ARG_MAX.

Committed as rS301763.

New patch with proper header file installation (thanks for the example).

Looks good to me.

Hmm, random() is already slightly unpredictable because various parts of the kernel use it, so the determinism of srandom(1) is not really there anyway ;)

Looks good to me.

To be honest, I don't see why libkern needs to deviate from common convention (including POSIX) here. What problem is being solved?

I think it is best to use run_rc_script in service and to add a function to rc.subr that determines name from $0/$file/$_file. This will work with the current openvpn rc.d script (versions from older ports branches are not relevant). The function in rc.subr can be used from such time as that older service that grep for ^name= are obsolete.