Adopt Gleb's suggestion on __inline -> inline (other places need that change too) :)

Testing is a good thing so I think this is well worth having. I will say on the rumor of name changes inside tcp_hpts due to the idea of possibly supporting
more than just TCP. I am unsupportive of this UNTIL we have tcp_hpts being able to handle multiple protocols. When I originally wrote hpts (called pacing not hpts.. Robert
renamed it hpts) I did envision expanding it to include not just TCP but SCTP and maybe even UDP. But the fundamental problem I hit was the fact that choosing where
to dice the thing such that you would have a common call point into the protocol was not a cut and dried thing. For TCP it was easy since there was a clear demark between
the initial input of the packet and the actual segment processing, which I used when I broke out the multiple stacks idea. However for SCTP and UDP no such clear
basis exists that is common with TCP..... or even between SCTP and UDP... so I back down and decided to implement it has a TCP thing. Now if someone comes up
with a clean and elegant way to call into to TCP/SCTP and UDP then name changes would be appropriate within the code.. without that elegant set of proposed
changes name changes I am STRONGLY against and will object to since they are just irrelevant until HTPS can support multiple protocols... so in summary

In D50019#1141170, @ivy wrote:

here's the thing though, you can already accept TCP connections to an anycast address by simply not marking the address as IFF_ANYCAST, and this is what everyone does today. if you force users to set a sysctl to do this, they will just not bother marking addresses as IFF_ANYCAST and will be more likely to run into problems from e.g. accidentally originating outgoing connections from an anycast address.

or in other words, the choice here isn't "should we let users accept TCP connections to anycast addresses?" because it's impossible to prevent that, it's "should we allow users to correctly mark their existing anycast addresses as anycast addresses?". i don't see any advantage to forcing users to set a sysctl in order to configure networking more correctly.

more sysctls is more confusing and creates more pain for users, removing special cases and unnecessary code is more beautiful. :-)

however, i would be willing to add some text to ifconfig.8 to mention the potential issues with TCP anycast and refer them to some appropriate documentation.

How about a compromise here... I do think Michael has a valid point...

Only question I have is why the change from hlen -> sizeof(struct ip6_hdr)

To me this is marginally less readable in the changed form. Both are much better than the original but considering your comments about what the compiler actually does I suggest we leave it the way it is!

Note I do agree with Gleb here, these macros are just nasty and not very clear. However I think that making such a change should be a separate commit from this one!

I agree with Peter :)

old code :)

Are you sure this condition cannot be reached?

In D47925#1095113, @glebius wrote:

Later I'd probably bring the input and output to same KBI, so that both return same signedness error for unlocked return. But this requires a sweeping change over stacks, so later.

Ok after a detailed analysis:

I agree with Michael here, macros badly hide things.. which is their intention :)

Fix what I thought I had fixed i.e. Unused_71 .. but for some reason I missed it ⭕

go through all the enum's and mark UNUSED those that are not used.

I am fine with this Drew, just went through and verified the departure code running earlier should have no impact...

This changes the enum, as discussed on a previous conf call to be "UNUSED" still taking the slot. I don't necessarily
agree with that but if everyone else wants it I am fine with it :)