What steps did you take to make sure that this assert is unreachable?

In D3834#90773, @Fabien wrote:

@deadalnix It's already the case, see D2681 or D2755. Also I have D3835 that will take ownership even more, but make your life easier for testing with buster.

Are you really confident you want to take ownership of this?

This breaks the set of warning when building standalone.

Make it version 7.x or something. From a major version to another, clang format do change how it formats some things.

Looks good overall, but it looks like there are leftovers.

There is a risk of collision doing it this way. Adding the hex code of the invalid character or something would be preferable. But this isn't meant to be used billions of time, so it can do for now.

The test plan is a mix of comments and command without distinction, which makes it impossible to follow.

f scope is narrowed, then the warning was removed from the rest of the codebase. This is a net negative.

Does this detect issues from D3795 ? In any case; this is good.

This kind of stuff should definitively have a linter. clang-tidy seems like good candidate.

Make sure we have strictly less than 32 pubkeys

bottom => first

Add mixed ECDSA/Schnorr test cases.
Fix various typos.

I don't see any point in removing warning for which the codebase is green.

You should consider changing the script to use a regex or something.

This doesn't look like it's going to be very useful if thins are working this way as we'll keep forgetting to add files in there.

There are 2 more instances in the codebase.

Rebase and clarify logic.

Include stddef to get size_t

Make the size unsigned.
count => size