Thanks for the review @imp. I'll land this series shortly.

Updated using git-arc to make sure they are in sync

I still think this is a good change, fwiw.

Reid can you confirm the author info for this commit? I can use "Reid Linnemann" <linnemannr@gmail.com> from Phabricator or the Netgate email if that is applicable.

This has been committed to head and MFC'ed to 14.

In D7986#1184580, @kbowling wrote:

@imp if I recall this was something we were looking at on my team at LLNW, if it were in Bugzilla I'd say "Close - OBE" is appropriate.

@cc since you've been working on CUBIC lately, the only thing possibly still relevant here is turning the first level if into the early returns.. it removes one level of indention which might help justify a couple other nearby style(9) fixes but it's not worth holding this review open.

This is (still) a sensible thing to do.

In D5650#1184327, @imp wrote:

In D5650#1184157, @brooks wrote:

This probably shouldn't land in quite this shape, but I'd really like avoid shipping FreeBSD/RISC-V+CHERI with never support symbols. There's always libc.so.16, but that might be too exciting and someone would have to organize the purge...

So the question is: is this review close enough to a good solution to keep open? Or should you steal the idea, with credit, and get on with it?

In D7600#1184549, @imp wrote:

Not sure this is a good idea, not sure it isn't. Tagging for review by srcmgr unless original author thinks it should be abandoned.

Actually, this is wrong. reallocf will return argv when we can't allocate new memory. So we'd never hit the warn and return.

@imp if I recall this was something we were looking at on my team at LLNW, if it were in Bugzilla I'd say "Close - OBE" is appropriate.

errr, jtl

code looks OK, though my arm assembler is rusty. tagged as srcmgr for review

tagging for srcmgr review. These are all likely a sea of conflicts now, but that should be easy to resolve.

In D5650#1184157, @brooks wrote:

This probably shouldn't land in quite this shape, but I'd really like avoid shipping FreeBSD/RISC-V+CHERI with never support symbols. There's always libc.so.16, but that might be too exciting and someone would have to organize the purge...

The feature was needed in Cambridge because of $infrastructure imposed on one. I haven't used it ever since and not anymore there either given they started a "Lab" network or we had our own FreeBSD host to boot from.

This probably shouldn't land in quite this shape, but I'd really like avoid shipping FreeBSD/RISC-V+CHERI with never support symbols. There's always libc.so.16, but that might be too exciting and someone would have to organize the purge...