dereferencji wskaźnik łamie surowe przepisy anty-aliasingu za pomocą gniazd Berkeley

Question

Mam kodu, który wygląda mniej więcej tak, gdzie addr jest sockaddr *:

struct sockaddr_in *sin = (struct sockaddr_in *) addr; 
const char *IP=inet_ntoa(sin -> sin_addr); 

Uważam, że to bardzo typowy kod za korzystanie Berkeley gniazda.

Jednak, kiedy mogę skompilować to, Dostaję następujące ostrzeżenie:
dereferencing pointer 'sin' does break strict anti-aliasing rules

szukają w internecie, znajdę jakąś dyskusję o tym, że droga Robię rzeczy jest dość typowe, ale ten Ostrzeżenie dla kompilatora również jest całkiem realne i nie jest dobre.

Jaki jest właściwy sposób ponownego napisania tego kodu, aby naprawić ostrzeżenie, a nie tylko go wyciszyć?

Answer 1

Jeśli plik nagłówkowy i kompilator są częścią tej samej implementacji C lub C++, zgłoś się do dostawcy i poproś o umieszczenie odpowiedniego #pragma w pliku nagłówkowym, aby uciszyć ich kompilator. Jako implementator mogą grać w takie gry, o ile zapewniają zgodną implementację.

Jeśli twój plik nagłówkowy i kompilator pochodzą z dwóch oddzielnych implementacji C lub C++, masz szczęście, że wszystko działa tak dobrze, jak one, i musisz rozwiązać to samodzielnie.

Answer 2

W zależności od sposobu użycia struct sockaddr, myślę, że albo Twój kod jest uszkodzony, albo gcc jest zepsuty. struct sockaddr i mają wspólny początkowy element (sa_family/sin_family), więc nie naruszają reguł aliasingu, jeśli dostęp do tego elementu odbywa się tylko przez oba wskaźniki; uczynienie tego jest dozwolone przez C99. Ponadto struct sockaddr nie ma innych elementów, do których masz dostęp. Jest to w dużej mierze rodzaj nieprzejrzysty dla prymitywnego polimorfizmu adresu gniazda. Jeśli kręciłeś się w wewnętrznych partycjach związanych z implementacją w struct sockaddr, lub jeszcze gorzej, jeśli zadeklarowałeś obiekt struct sockaddr, a nie tylko wskaźnik lub wykonane kopiowanie pomiędzy takimi obiektami, Twój kod jest uszkodzony. Jeśli nie, a gcc ostrzega, że ​​złamałeś zasady aliasów, generowanie ostrzeżeń gcc jest zepsute. Na pewno nie zdziwiłbym się, gdyby to było drugie.

Answer 3

Tak, jest to znany problem z gcc i gniazdami. Problem w zasadzie wydaje się taki, że sposób, w jaki zaprojektowano ten ip [46], jest niezgodny z założeniami, które ludzie gcc sądzą, że mogą wydedukować o aliasingu wskaźników.

zwykle uciec z tego najpierw biorąc wskaźnik na struct

struct in_addr* act = &(sin->sin_addr); 

a następnie za pomocą *act.

Answer 4

Miałem ten sam problem - wygląda na błąd w gcc.

udało mi się obejść za pomocą

(*sin).sin_addr 

zamiast

sin->sin_addr