When I applied this change locally to take a look git reported a couple of whitespace issues, identified above.

Then I ran clang-format12 against sys/netinet/libalias/* and put the result in D30260, as part of ongoing efforts to evaluate the possibility of using clang-format for automated code formatting. (No intent to run it over the whole tree, but using it as part of our patch submission process.)

clang-format has a few deficiencies right now and there are some significant things that are just wrong in D30260, but it did identify a few additional style items that can be applied

I do not take every hint from D30260.
Many of those compiler generated suggestions destroy the flow of reading.
Most of the others are a bit picky on the line length, but this is not reason to change existing code.

I'd be happy to commit this as a base for future work.

In D30259#679921, @donner wrote:

I do not take every hint from D30260.
Many of those compiler generated suggestions destroy the flow of reading.
Most of the others are a bit picky on the line length, but this is not reason to change existing code.

Indeed - I opened D30260 to show some examples of other things that might be missed, and as an opportunity to see how clang-format compares as this code already had active interest in style(9).

My main goal with clang-format is that we can get to a point where we can tell submitters to just use git clang-format (which formats just the changed lines) to produce an acceptably-well formatted patch.

I'd be happy to commit this as a base for future work.

I agree with committing this and following on with your performance/other changes. I'll leave D30260 around for now if there's more to discuss with others on improving clang-format, but do not intend to commit it.

Thanks for taking this on!