I do not see how nargs is the correct value to use here; it has a different meaning to the program, and can be overridden by other command-line arguments, giving a bizzare behavior change if -n 1 -P 0 are passed in different orders.

Good point. I didn't trip this up by pure coincidence.
Let me think of a different value to use.

Why allow value larger than RLIMIT_NPROC or _SC_CHILD_MAX? Soft limit would cap number of processes sooner. And kern.maxproc can be larger than "infinity" hard limit.

$ limits -Su 50 sh -c "yes | xargs -n1 -P0 yes foo" >/dev/null &
$ pgrep -f foo | wc -l
       6

$ limits -Su
Resource limits (current):
  maxprocesses-cur          100
$ limits -Hu
Resource limits (current):
  maxprocesses-max         1458
$ sysctl kern.max{proc,users}
kern.maxproc: 1620 # (20 + 16 * maxusers)
kern.maxusers: 100

style(9) doesn't allow both <sys/types.h> and <sys/param.h> included at the same time.

Why? Other uses of strtou*() in the file or across the base don't use macros for integer bases.

usr.bin/xargs/xargs.c:                  Rflag = strtol(optarg, &endptr, 10);
usr.bin/xargs/xargs.c:                  Sflag = strtoul(optarg, &endptr, 10);

http://bxr.su/search?refs=strtou*&project=FreeBSD

This was recommended by davide@
I can change all of the references, or remove the macro.

@davide has phabricator account. Let's ask him for the the rationale. I don't see his feedback here, in the bug or on freebsd-current maillist.

Yeah, it was on IRC:
<davide> AllanJude: you don't do upper bound validation on the number of processes
<davide> AllanJude: '10' is hardcoded and makes hard to understand what that's actually about
<AllanJude> the 10 is the 'base'
<AllanJude> it is a standard argument to strtol
<davide> AllanJude: I can read the manpage
<davide> AllanJude: it should be a macro
<AllanJude> there is a macro for decimal?
<davide> #define BLAH 10 ?
<AllanJude> so, I should make one?
<davide> otherwise, lgtm

RLIMIT_NPROC won't mean anything to the end user.
How about changing the line to just:
errx(1, "max processes must be less than %d", proclim);?

"at a time" is kind of weird at the end of this sentence. It could be removed without changing the meaning of the sentence, or maybe reword for better clarity.

Why would a negative value be allowed? gnu xargs does not allow one. This sentence does not mention the upper limit present in the code (and erroring out if not met), which is actually a good thing since the limit should be removed.

I also don't see what's the point of of this deifne.

Why is this set here?

The code form user perspective should behave just like gnu xargs, unless there is a good reason to deviate, which I don't see.

In this particular case, they have "unlimited" for an argument == 0, specified limit for > 0 and error out for non-numbers and negative values. Here negative values are accepted for some reason.

One big not-user-visible difference is the fact that gnu xargs dynamically resizes the process table, while our xargs allocates it upfront. This means we have to have a reasonable limit which can pose as "unlimited" for practical purposes.

getrlimit seen here is fine enough.

However, the code must not complain about passed limit being bigger. It should internally cap it to getrlimit so that user-visible behaviour is identical with gnu in this respect.

As a result the code should explicitly coompare maxprocs to 0 (as opposed to < 1), proclim variable has no use. Fetch rlimit /after/ maxprocs is validated. If (maxprocs == 0 || maxprocs > reslimit.rlim_cur) maxprocs = reslimit.rlim_cur;

getrlimit realistically should never fail, so a failure with err(1, "getrlimit"); should be fine enough for surprising cases.

sys/types.h must be included prior to sys/wait.h.

I would rename this to rl or rlimit, as a nit.

The current text is good, but I wonder if this is better:

If
.Ar maxprocs
is set to 0,
.Nm
will run as many concurrent processes as possible.