Take care of the similar case in vtnet as well

Makes sense, right. I'll take care of it shortly. Thanks!

Sure thing. I actually wanted to keep this separate since this one is basically just a clamp while the other one in vtnet is IMHO more of a logical and policy change (and I needed to test that even further, to be honest). But since both are addressing the same concern (namely, not trusting the host to stay within the buffer) it could indeed make sense to have them both done here. I’ll take care of it tomorrow.

Looks good to me, thanks!

Looks great. Thanks, Devin!

Looks good to me now. Thanks!

I wasn't planning to include a description in the commit body, but perhaps a brief explanation like the one above would be useful?

This is required to prevent function-like macros with the same name from being expanded in the definitions once they become active in a later C mode. Without the parentheses, the declarator is rewritten and will not compile. This style is used for similar cases such as mempcpy() too.

Diff 7/8 looks good on the INIT-REBOOT RELEASE/disassoc path, but ignore ipv6only doesn't seem to be a real opt-out.

Same here, I’ve been testing it for a while now, and it has my approval as well. Thanks a lot for all the effort, Pouria!

Drop sizeof(mbstate_t) - sizeof(_Char8State) >= 64 for now

Mark review comment on _Mbrtoc8Extra as done, as it is no longer applicable following the changes that were implemented.

Rename _C8rtombExtra to _Char8State for consistency

Mark several review notes as resolved: Björn Höhrmann’s DFA implementation, __cpp_char8_t rationale, u8'\0' clarification, c8rtomb licensing, data type improvements, the states enum, urtf8d table formatting, and unit test improvements.

Thanks for your notes! Sure, I’ll keep them in mind and take care of those herein in a minute.

Address the remaining review points

Address the three promised review points

Sorry if I made some modifications to what you sent me via email. I actually thought I was allowed to, as it isn't finalised yet and we're working through it together. I'm just trying to make sure we're not rushing things and that we're on the same page as we go along, for future maintenance and stuff we'd be working on together. I certainly don't mean to be rude or inattentive. Also, thank you for putting so much time and effort into reviewing everything, explaining things, and discussing it all with me, and being this much receptive and kind throughout. I really appreciate it.

Nice move. Thanks!

Default MK_ICONV=yes now runs mbrtoc8/c8rtomb through Citrus like c16/c32, and unsurprisingly, we now inherit its bugs as a result: null s resets, ill-formed input often comes back as (size_t)-2, 5-/6-byte UTF-8 (as with RFC 2279 §2—obsoleted by RFC 3629 §3) and values above U+10FFFF are accepted, U+FEFF fails, and each mbstate_t leaks. Those need an iconv fix, though, so not c8 special cases. FWIW, WITHOUT_ICONV c8rtomb stays C23 in (c8rtomb.c / mbrtoc8.c), and mbrtoc8 matches mbrtoc16.

Brilliant work. Thanks!

Thanks, Robert! Sure, I will do.

Move __WCHAR_WIDTH into sys/sys/_types.h

If the size is the same on all platforms, it should not be in the platform-specific _types.h files.