In D56865#1302516, @jrtc27 wrote:

But won’t we have built elftoolchain strip in that case?

address feedback

In D56491#1293768, @markj wrote:

I tried applying this patch and building world on FreeBSD running recent main. I can see that MK_ASAN and MK_UBSAN are getting set properly, but if I trace process args during the bootstrap-tools phase, I can't see -fsanitize getting passed anywhere. Am I missing something?

Almost certainly an accidental omission

No longer needed

ping?

In D52526#1228287, @jrtc27 wrote:

In D52526#1228284, @arichardson wrote:

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

Thanks for committing this. Do we still need the && defined(__USE_GNU)? Technically it's needed but I guess this file is only every compiled with -D_GNU_SOURCE so probably doesn't matter?

Yeah I don't think this is the first place we assume _GNU_SOURCE is in use (and I doubt it builds without), and I'd rather not poke at internal defines if at all possible (i.e. only add it if we ever end up in a case where we get the non-GNU prototype with glibc).

In D52526#1228266, @jrtc27 wrote:

I forgot about this revision and ended up reinventing it in 4dd2b869cd078ed6f40c42d1ef429222da16a58f and 34e7a57673c9730ee5d1f7ebb07e152567bd8e0b so it should be fixed in-tree. I did however retain the knowledge about Clang's bugginess wrt __gnu_linux__ (and wondered where I'd got that from...) so did not use it myself... I did also check musl matched us rather than glibc.

In D52528#1200432, @emaste wrote:

commit message disagrees with __nonstring?

In D52563#1200450, @sjg wrote:

No need for a comment, I committed the following upstream:

Index: var.c
===================================================================
RCS file: /cvsroot/src/usr.bin/make/var.c,v
retrieving revision 1.1171
diff -u -p -r1.1171 var.c
--- var.c       29 Jun 2025 11:02:17 -0000      1.1171
+++ var.c       16 Sep 2025 15:13:28 -0000
@@ -1850,7 +1850,7 @@ QuoteShell(const char *str, bool quoteDo
 static char *
 Hash(const char *str)
 {
-       static const char hexdigits[16] = "0123456789abcdef";
+       static const char hexdigits[] = "0123456789abcdef";
        const unsigned char *ustr = (const unsigned char *)str;
 
        uint32_t h = 0x971e137bU;

Okay it looks like musl does not have the weird char* strerror_r: https://git.musl-libc.org/cgit/musl/tree/include/string.h#n66, so it will need to be conditional on glibc.

rebase

rebase

rebase

rebase

In D52531#1199810, @emaste wrote:

Note: This patch should be a separate commit and not merged.
For testing purposes they are combined.

This seems confusing in the commit message

silence warning instead

avoid sys/types.h includes, and update test list

In D52041#1188826, @imp wrote:

Do you need sys/types.h, or sys/_types.h? The latter has less namespace pollution...

And if these are on the excluded list for check headers for buildworld, please remove them.

In D52041#1188826, @imp wrote:

Do you need sys/types.h, or sys/_types.h? The latter has less namespace pollution...

And if these are on the excluded list for check headers for buildworld, please remove them.

This looks sensible to me. One suggestion would be to avoid the manual caching.

In D46403#1057696, @jrtc27 wrote:

In D46403#1057695, @arichardson wrote:

In D46403#1057654, @kib wrote:

In D46403#1057647, @arichardson wrote:

In D46403#1057619, @kib wrote:

Could it be simplified by providing an fcntl variant that takes the third arg unconditionally, instead?

I would also be happy with that approach, just assumed this variant would be more flexible. Would the unconditional one look like this: fcntl2(int, int, __intptr_t)?

The actual syscall takes three args unconditionally, so there is no point in adding more complications IMO. By existing conventions, the function perhaps should be called fcntl3.

Actually, I just remembered this would not help with the interposing of fcntl since the interposer would still need to extract the variadic argument.

Well, fcntl would call fcntl3, and you can then interpose the latter, just as with vfcntl.

In D46403#1057654, @kib wrote:

In D46403#1057647, @arichardson wrote:

In D46403#1057619, @kib wrote:

Could it be simplified by providing an fcntl variant that takes the third arg unconditionally, instead?

I would also be happy with that approach, just assumed this variant would be more flexible. Would the unconditional one look like this: fcntl2(int, int, __intptr_t)?

The actual syscall takes three args unconditionally, so there is no point in adding more complications IMO. By existing conventions, the function perhaps should be called fcntl3.

review comments