Одно из двух.
а) Либо так называемый reinterpret_cast или type pun — берётся кусок памяти serv_addr неизвестного типа и рассматривается как совсем другой тип, sockaddr_in. Корректность такого «взять кусок памяти и рассмотреть как другой тип» остаётся за программистом, возможны тонкие ошибки кроссплатформенности.
б) (в данном примере, скорее всего, нет, но тоже бывает) Либо так называемый const_cast — переменную, отмеченную как const, мы рассматриваем как неконстантную того же типа. Опять-таки, корректность такого преобразования остаётся за программистом: если переменная окажется в неизменяемой памяти, а мы её решим изменить, будет нехорошо.
То и другое — либо сильно обобщённый код оперирует указателями «на что угодно», либо какая-то разглючка, либо плохая архитектура, либо последствия того, что где-то приходится опускаться на самый низкий уровень (обработка сообщений Windows, плагинная система).
Подобное преобразование типа выполнено в стиле Си (взять указатель на переменную и преобразовать в другой тип-указатель).
Кстати, в коде ещё одна ошибка кроссплатфроменности — константа -1 только для Linux. Портабельно — макрос SOCKET_ERROR.
UPD. Это именно что reinterpret в сильно обобщённом (и сильно системном) коде. Функция connect принимает указатель на кусок памяти, который состоит из двухбайтового названия протокола и сетевого адреса произвольной длины (тип sockaddr). Тип sockaddr_in — это как будет эта выглядеть эта память для адресов IPv4 (протокол AF_INET). Одна и та же функция connect может подключаться по IPv4, IPv6, Apple Talk, Bluetooth и куче других протоколов, ныне известных разве что историкам. Другой протокол, другое AF_, другие sockaddr. Так что берём версию для IPv4 (sockaddr_in), заполняем её и передаём в connect, преобразовав в «более общий» тип sockaddr. Опознав, что имеем дело с IPv4, функция connect снова проинтерпретирует эту память как sockaddr_in.
Простой
