In D53062#1212373, @emaste wrote:

Do they get placed in rodata with the change?

Also I think the commit message ought to reference any changes in ELF sections containing these.

In D53026#1211680, @des wrote:

In D53026#1211606, @markj wrote:

The only case in which the userland implementation would return a different error than the system call is if we are racing against someone modifying the hierarchy we are traversing

How do you know this? It seems possible that there are some corner cases which __realpathat() simply doesn't handle.

Such as?

The only case in which the userland implementation would return a different error than the system call is if we are racing against someone modifying the hierarchy we are traversing

In D52983#1210842, @kib wrote:

In D52983#1210802, @markj wrote:

This should be documented in mount_nullfs.8. The implementation looks ok to me.

I will after the patch is finalized.

The name sounds a bit strange to me. The mount_nullfs terminology explains what "bypass" means, but it's still a bit unclear IMO. What do you think about unix_private, nounix_private?

For me, 'private' is worse. What exactly is the scope where the socket becomes private? People would think about jails or whatever namespace restriction they intend, but not the pass from upper to lower.
I can rename user-visible option to unixbypass e.g.

Just clear the whole struct

Clear a couple of other fields.

This should be documented in mount_nullfs.8. The implementation looks ok to me.

Seems ok to me.

In D52933#1210529, @brooks wrote:

In D52933#1210494, @markj wrote:

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

Certainly. I don't think we care about things before 15, probably closer to 17. I wasn't able to determine when __has_builtin was added, but there was an issue with non-function-like builtins fixed in 10 and these are function-like so were fine even then.

What's wrong with simply redefining __GNUC_PREREQ__ here though?

It's a GNUism and pretty meaningless on with clang (which pretends to be GCC 4.2.1).

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

In D52933#1210459, @brooks wrote:

Could we not just swap the order of the checks in stdckdint.h so clang never evaluates __GNUC_PREREQ__? We're already requiring at least an always-false __has_builtin in the next section in cdefs.h.

That being said I don't think we care about except in the most abstract sense about gcc 9 support for a C23 header.

I'm ok with this change landing.

In D52733#1205031, @olce wrote:

In D52733#1204959, @markj wrote:

Actually, it's vm_thread_stack_create() that I had in mind. I fail to see any locking here.

Don't test /usr/local/etc/rc.d/*

Apply Warner's suggestion.

In D52933#1209484, @emaste wrote:

Seems OK, although I wonder if __has_builtin(__builtin_add_overflow) will be true on GCC versions that are still relevant (and we could remove the __GNUC_PREREQ__ from stdckdint.h

Note that I am not 100% sure this can actually happen, since I am not 100% sure we will ever enable interrupts before we run mca_setup().