Historically, another reason was performance. For example, https://svnweb.freebsd.org/base?view=revision&revision=76801 which changed make(1) to be statically linked states performance as the reason.

Looks good with one grammar issue. Don't forget to bump .Dd.

This seems useful.

In D21903#478488, @kevans wrote:

In D21903#478452, @kib wrote:

I find it somewhat strange that you require global control to enable local setting. Less cryptic, I would expect to see per-process setting of 3 cases: 1. default/use sysctl, 2. enabled, 3. disabled.

Very useful, and good generalization of shm_open(SHM_ANON) and memfd_create().

Add more volatile

Add another testcase for access past end of non-empty object

I like that this makes signal numbers and codes more architecture-independent and reduces the number of conversions of this information.

Documentation for the _ variable was indeed missing.

Remove no longer used variable MAX_TRIES

This change looks reasonable, although the exact logic can be improved as noted. It may have been the original intent that $start_cmd use $_env by itself but that would involve replicating error-prone code.

This seems to fit the model.

Looks good to me.

Perhaps it's better to convert ps to use getopt_long() so that we do not invent new single-letter options.

In D20969#455437, @darius-dons.net.au wrote:

Definitely a generic way of achieving this would be nice, and it looks like you can set umask with a login class - to be honest if I had known about the "${name}_login_class" before now I would have used that rather than writing this patch.

Perhaps it will be more generically useful to add a ${name}_umask variable to rc.subr instead.

In D19902#437991, @hrs wrote:

In D19902#437962, @jilles wrote:

Perhaps it is cleaner to pass the int age to be searched for by reference. However, the asymmetry in the compare function is intentional as this allows finding an object with more data given the key, while having only one storage array.

I think it will be useful to have this. It fixes most of the drop in functionality when moving from System V shared memory to POSIX shared memory.

In D19902#437950, @hrs wrote:

As already pointed out on the mailing list, this example has a lot of problems which are not only style bugs. Ones I think as critical except for the style issues are the following:

• The function to compare two elements should accept the same type, not using an "age" field value by using a pointer type. It is a function to compare, not look up a matched element in the definition of bsearch(3). Passing a raw value as (void *) type is not impossible, but it is not suitable for a "textbook" example.

The new function sbuf_printf_drain was added recently enough that this should be safe (binaries using sbuf_printf_drain linked against the old libsbuf.so.6 will not run against the new libsbuf.so.6).

In D20111#433337, @asomers wrote:

In D20111#433326, @jilles wrote:

In D20111#432908, @asomers wrote:

Not so fast! I just discovered a serious footgun: Linux's struct dirent has a
d_off field, but it's meaning is different than FreeBSD's. That's worth
mentioning.

In D20111#432908, @asomers wrote:

Not so fast! I just discovered a serious footgun: Linux's struct dirent has a
d_off field, but it's meaning is different than FreeBSD's. That's worth
mentioning.

It is indeed important to ensure that this is the complete kernel assist for posix_spawn, so we do not leave multiple versions of this around, each with their own flag.

The general approach seems good.

This seems a good approach to make things work. Malloc typically uses mutexes, so it makes things much easier if mutexes do not use malloc.

In D18926#406366, @se wrote:

I'd do not like the conversion to floating point for numbers outside the range of 64 bit integers. They violate assumptions I'd like to be able to make (e.g. that adding and then subtracting the same number leads back to the initial value in all cases).

Add test for [ERANGE] special case.

In D18926#405742, @se wrote:

The behavior is not consistent for shell arithmetic operating on parameters with or without "$" (e.g. "$((X))" vs. "$(($X))") for variables not in the range of valid integers.
This may be allowed by the standard, but is still somewhat surprising:

My original objection to \u is no longer valid since we have accepted that the ugly \ bash prompt sequences are staying.

The BLOCKSIZE assignments in share/skel are not "wrong" as such, but BLOCKSIZE seems a configuration option of little use in general. Most of the time, the -h option is more useful.

I wonder when it is appropriate to run pwd_mkdb without -p. Only when etc/passwd is considered legacy and needs to be omitted from the system?