Looks good to me. Thanks!

In D59288#1360867, @fuz wrote:

Approved for commit following @kib's review. I did not review the code, so only Approved by from me please.

Add new symbols in alphabetical order and apply @kib's fenv.3 suggestion

Is it reasonable to provide the inline versions of these methods for complicated cases, like x86? Could it be always a function call?

Address @kib's inline comments

This should be reviewed by kib, andy (for ARM), jrtc27 (for riscv64), jhibbits (for ppc), and kargl (for msun).

Document mbrtoc8() and c8rtomb() functions

This seems to be correct at first glance, but I think it can be greatly simplified and improved in performance.. I did a lot of research on Unicode validation and transcoding and had originally meant to take a stab at this function, but then forgot about it.

I'll think about it some more and then let you know what I came up with.

I’ll take care of manpages in the coming days.

Sure!

Sure thing. I'll take care of it.

Thanks a lot for your notes, Devin. I can see it much more clearly now, and I understand why 1:1 is the preferred approach. I’ve just updated the summary with the message for the squashed commit, and I’ll push my changes shortly.

I do have some questions about the summary on this review though. Seeing 3 separate commit sections, how do you intend to commit this?

Looks good to me. Thanks!

Update commit messages

Address @fuz comments

• bsearch.3: Document bsearch_b extension
• libc: Add bsearch_s() from Annex K
• libc: Add tests for bsearch(), bsearch_b(), and bsearch_s()

Looks good to me, but while you're here, could we also map IFT_LOOP -> LINUX_ARPHRD_LOOPBACK so a Linux ip link show lo under the linuxulator does not look like FireWire? The constant already exists. Fine as a follow-up if you want to keep this patch to bridge/vlan/stf.

Looks good to me. Thanks!

It's brilliant. Cheers!.

Sure, thanks!

The bsearch_b documentation is handled in a separate commit. It displays correctly for me here in Phabricator, but I’ll shortly update the description with the proposed commit messages, as we’ve agreed to use that convention to make reviews easier and clearer. And as for the tests, sure, I’m working on it; I do my best to submit the commit by tonight.

Sure. Thanks!

Finalise commit messages and improve the geliboot_internal.h comment block

OK, I’ve taken a look at similar cases throughout the file and reviewed the commit history, and it sounds like I’ve got it right. Ready to push these changes shortly.

The news.toml file is in reverse chronological order, so after rebasing I placed mine before the most recent 14.5-BETA1 announcement as it is six days after my joining date. Is that correct?

Rebase

Thank you both. I really appreciate all your help and support.

Update metadata with Robert’s approval and fix typo from the opening commit

In D58700#1347007, @dteske wrote:

Alternative to .mailmap is freefall:/var/forward/kfv

Update commit messages; will update metadata if fuz@ provides approval by the time we commit.

I just checked the internal/admin branch, and it’s most likely due to the missing entry in the mentors file.
I just discussed it with Devin, too. I’ll try pushing again once access is granted.

@fuz: I don't have access to the docs repository. Am I expected to handle this myself, or do we need a docs committer to take care of it on our behalf?

In D58699#1347018, @dteske wrote:

Looks good to my eyes. Please update the summary to include proposed commit message (is how I was mentored -- it was a long time ago, but I agreed that it was good to give mentors a preview of what was to land so they could head-off any potential criticism since the commit itself is sent to every committer while the review is narrow in scope to who sees it)

Address Robert's note on Reviewed by: field.

Has @dteske reviewed or approved of this DR? I don't see it anywhere. In any case, adjust the commit message to reflect who actually reviewed and gave approval when you land.

I have included dteske's approval in place since she's aware of the revision; I can update it if necessary later.

Update commit message in accordance with the Committer's Guide.

I'll update the patch with the required metadata fields once it's approved.
Please let me know if there's anything else that needs to be addressed.