• Cleanup and document

• Remove last new #error

• Convert #error to #warning

So, I ran egrep -r '__[A-Z0-9]*_VISIBLE' /usr/ports and now I'm very sad.

• Actually undefine things we say we do.

• Typo

• Honing in on requirements
• Allow C version to be upgraded via _CXX_SOURCE and _ISOCXX_SOURCE

So I think there's really two classes of things it would be nice to define/enforce... what we do with a _*_SOURCE conflict, and what we do about a user defining __*_VISIBLE.

In D49423#1127234, @imp wrote:

I also noticed that if you ask for _XOPEN_SOURCE 800, you get POSIX_C_SOURCE of 202405 unconditionally and irregardless of what you'd defined earlier.
And defining POSIX_C_SOURCE takes precedence over all the other _FOO_SOURCE things, which kinda is backwards I think.

• More enforcement

In D49423#1127228, @imp wrote:

I need to update the XOPEN_SOURCE and POSIX_C_SOURCE part of cdefs(9) to indicate the 'paired values' that are legal. Like 800 and 202405.
And there's values implied by different POSIX_C_SOURCE as well wrt language defines. When paired with a language standard, these combos should likely be allowed. POSIX_C_SOURCE 202405 and I think C23 or 200809 plus C99, etc.
So pedantically, you should pick one or the other, we may need to relax a little to allow the different pairings that make sense together.
Do you think it would make sense for me to update cdefs.9 to include this matrix?

• Warn/error on conflicting programming environments

• Error on conflicting programming environments for exp-run

I wonder if it's a good idea to take on the whole set of mutually exclusive environment selection macros with this...

Hrm...

./usr.sbin/rtsold/rtsol.c:#define	__BSD_VISIBLE	1	/* IN6ADDR_LINKLOCAL_ALLROUTERS_INIT */
./crypto/openssh/openbsd-compat/fnmatch.h:#define __BSD_VISIBLE 1
./sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h:#define	__BSD_VISIBLE 1

Would these count?

Using || __BSD_VISIBLE on all of the symbols that were previously only under __BSD_VISIBLE will be needed for this to MFC, so perhaps do it here as well? (14.2 default __POSIX_VISIBLE appears to be 200809)

Revert was pushed. See https://reviews.freebsd.org/D49423 for v2 of the patch.

Revision pushed as 415a0ce02c9ee2c15c7973b2dfbddda71f6344a2

Alternatively, I have a revert commit ready as well:
https://reviews.freebsd.org/D49422

Thanks for the review, I'm very happy to have a picky reviewer on this one especially.

• Remove extra XX comment

• More feedback

It may be worth noting that the only example of SPDX in style(9) that I see has SPDX before the copyright.

• Address feedback

Looks good, thanks!

• Remove unneeded headers

• Update .c file per style(9) as well.

• Another typo, CPIO -> GPIO

• was->were

• Address manual feedback

• Fix copyright and update wrapping

• Fix copyright

Pushed as 513f684dcfa8fe242cc540ddb65793eacdd14b34

I guess there's no hamradio@ group in here.

In D48571#1107815, @jrm wrote:

• it might be helpful (at some point) to upstream the patch

Apply portfmt -D patch

👍

Asking for the src bit back though, wish me luck. :D

As it happens, I no longer have a commit bit... here's the message I was going to use:

Add more reviewers who have made/reviewed C23 changes to these files.

Adding reviewers, there doesn't seem to be a "standards" group.

Going on vacation for a couple weeks, and will look at this again when I get back... adding adrian@ as a reviewer, feel free to add more appropriate reviewers as actionable feedback will be welcome when I return.

• Update manpage

• Add macros for TLV types

• Retry reset command up to twice.

Tested with Google Pixel Buds A... with virtual_oss, pairs and right channel works.

• Fix comment.

• Add to devd

So yeah, looks fine to me, but I'm very out of touch with current iflib, so I'm inclined to not approve with my iflib hat on. My biggest concern was that someone may think it's the right way to handle the bits.