I also preferred the old version. But I changed it to this form on vladislavbelov's request.
See this: https://code.wildfiregames.com/D1676?id=6992#inline-31309
I can't really satisfy both of your opinions at the same time, so either you guys should agree on what is right or tell me which one of you two has higher priority.

@vladislavbelov saying so is enough for me :) Was just wondering because I didn't even know that could be done. Wonder what the scope of that status is in this case.

Why I vote this. Because you don't need to share the variable with all other code, only with the space where it's required.

If there would be another similar block, you would need to call all these variables by some meaning names.

@Stan the scope is the consequent of if statement (code inside {}). It is similar to for cycle in which you can also define variable in initialization part.

@vladislavbelov I prefer creating another {} block for limiting scope of variables. This seems ugly because it is not C compatible and it does not work in any other comparison case (such as equal instead of not equal or comparing to any other number different from zero).
And it also can lead to situations where one thinks he can modify the comparison such as

if (int status = getaddrinfo(...) == 0)

which doesn't work because status variable gets assigned 0 or 1 depending on result of comparison and the original result of getaddrinfo gets dropped.

I prefer creating another {} block for limiting scope of variables.

I can say that it's ugly about useless {}. But it's just tastes I think. I just prefer the if variable while it's compilable.

it is not C compatible.

Then you shouldn't use reinterpret_cast, STL and other C++ stuff here.

it does not work in any other comparison case (such as equal instead of not equal or comparing to any other number different from zero).

You're right until C++17 :)

And it also can lead to situations where one thinks he can modify the comparison such as

Yes, I agree. But it's a more complex problem, that people don't know the language. It should be solved on the review stage.

if (foo)\n
{

Why does this hardcode IPv4 and not have some condition for IPv6?

Becase this code is related to STUN. There is no STUN for IPv6. One of the reasons we want IPv6 is that there is no need for ugly stuff such as STUN.

There is no STUN for IPv6

Is that absolutely true or is there only one of the main historic use cases for NAT dropped?
STUN is used for NAT traversal, but IPv6 doesn't necessarily kill every NAT?
https://www.quora.com/Will-the-IPv6-result-in-the-death-of-STUN-and-ICE

Also since the StunClient was imported from supertuxkart, we might want to inform them in of the update once we merged it and if we find an active maintainer of this file.
(Also we still have a probable memory leak in the glooxwrapper since the StunClient commit (rP19703).)

I did not ever see any NAT on IPv6. And I hope I ever won't. Let's hope that people realize that it breaks way too many things and it is bad by design soon enough to not to implement it anywhere. If you send packet from IP address X and recipient receives this packet from IP address Y then there is something fundamentally wrong with the brain of the one who is responsible.

I think that IPv6 will kill NAT. I don't know of any ISP or router that would use NAT for any reason. When it comes to privacy random temporary addresses are usually used. When it comes to security stateful firewalls are usually used.
If we're ever gonna need some ugly helper such as STUN is on IPv6. It's probably gonna be to punch holes through stateful firewalls. You'd need to send packet from both peers first to establish working bidirectional UDP communication. But that would be much easier than STUN since no crazy things such as public ip addrees and public port detection would be necessary.
I don't know of any ISP that would implement such stateful firewall on their side. This is usually done in user's router which user usually has in control and can allow incoming connection on necessary port.
And it's probably better to lead users to learn how to setup their firewall rather than trying to overcome this somehow. Users will probably need this also for TCP and that's not that easy to punch through firewall as UDP is.
Anyway stateful firewalls are gonna be a problem only for hosts. They should not cause problems when joining a game.
Hopefully we're not ever gonna need to do anything and it will just work.

would make it inconsistent with current IPv4 code, wanna change that too?

Yeah in that case. It's better to know which type of cast we use :)

reinterpret_cast

Ok, use of getaddrinfo could be converted to function as well.

For me: fix ntohl -> htonl.

Not sure what ntohl is so can't really tell :)