2013-02-25 26 views
5

Mam projekt, który musi być zbudowany na systemach Windows, Linux i VxWorks. Projekt jest zbudowany na systemach Linux i Windows, ale skompilowany krzyżowo dla VxWorks. Aby poradzić sobie z endogennością na wielu platformach, używa ntoh.h. Maszyna z Linuksem jest mało endyńska, ale ntohl nie zamienia się w moim programie.Linux: ntohl nie działa poprawnie

Napisałem program testowy, który zawiera bezpośrednio in.h. To się odpowiednio zmienia. Napisałem kolejny program testowy, który obejmuje tylko ntoh.h. To się odpowiednio zmienia. Oba programy testowe łączą się z lib64/libc.so.6.

Jednak, gdy kompiluję mój projekt, ntohl się nie zmienia. Nie mogę się włamać do ntohl za pomocą polecenia gdb "break ntohl". Podczas budowania widzę ostrzeżenie LITTLE ENDIAN (patrz poniżej) i nie widzę błędu "SHOULDNT BE HER".

Proszę o pomoc. Nie rozumiem, dlaczego ten problem występuje.

Poniżej ntoh.h:

#ifndef __ntoh__ 
#define __ntoh__ 

#include "basic_types.h" 

#ifdef WIN32 
    #include <winsock2.h> 
#elif LINUX 
    #include <netinet/in.h> 

    //This is here to determine what __BYTE_ORDER is set to in netinet/in.h. 
    // Not in original code 
    #if __BYTE_ORDER == __BIG_ENDIAN 
    #warning BIG ENDIAN BYTE ORDER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
    #endif 

    //This is here to determine what __BYTE_ORDER is set to in netinet/in.h. 
    // Not in original code 
    #if __BYTE_ORDER == __LITTLE_ENDIAN 
    #warning YAY LITTLE ENDIAN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
    #endif 
#else 

    #error SHOULDNT BE HERE  //added for debugging purposes 
    #define ntohl(x)  (x) 
    #define ntohs(x)  (x) 
    #define htonl(x)  (x) 
    #define htons(x)  (x) 

#endif 

#endif // __ntoh__ 

Część mojego polecenia kompilacji:

g++ -DDAU_PARSER -DNO_MT -DTEST_CLOCK -DLINUX -g -Irelease/include -Irelease/include/Record_Data/ -Irelease/include/Utility -o dauParser DAU_Support_Tools/src/dau_parser.cpp DAU_Support_Tools/src/dau_parser_write_data_to_file.cpp Utility/src/Messaging/Communications/Message.cpp Utility/src/time_type.cpp Utility/src/collectable.cpp Utility/src/clist.cpp Utility/src/clock.cpp Utility/src/test_clock.cpp Utility/src/mutex.cpp Utility/src/ntoh.cpp ... 

Błąd jest generowany przez następujące linie:

int deadbeef = 0xDEADBEEF; 
printf("TESTING DEADBEEF %x %x\n", deadbeef, ntohl(deadbeef)); 

wyjście z tych dwie linie dają taką samą moc wyjściową. TESTOWANIE DEADBEEF deadbeef deadbeef

+2

Proszę dodać kod, który faktycznie nie działa poprawnie. – wRAR

+1

Od twojej edycji, jak to możliwe, że 'printf ("% x ", 0xdeadbeef)' tworzy 'efbeadde'? Możesz opublikować minimalny przykład pokazujący rzeczywisty kod. –

+0

@AustinPhillips: Przepraszam, masz rację.Opis wyników został naprawiony. – Kat

Odpowiedz

6

Dane wyjściowe z tych dwóch linii dają takie same wyniki. BADANIE DEADBEEF deadbeef deadbeef

Well, coś jest źle, ale nie możemy powiedzieć, co. Musisz rozwiązać ten problem, ponieważ jesteś jedyną osobą, która może go obserwować.

Zacznij możliwie najprostszy przykład:

cat t.c; gcc t.c && ./a.out 
#include <netinet/in.h> 
#include <stdio.h> 

int main() { 
    int deadbeef = 0xDEADBEEF; 
    printf("TESTING DEADBEEF %x %x\n", deadbeef, ntohl(deadbeef)); 
    return 0; 
} 


TESTING DEADBEEF deadbeef efbeadde 

Czy to produce oczekiwano wynik?

  • Nie: twój zestaw narzędzi i nagłówki są wyłączone.
  • Tak: Twój zestaw narzędzi jest w porządku, ale Twój rzeczywisty kod robi coś innego niż w przykładzie.
    Uruchom kod za pomocą preprocesora: gcc -dD -E -DLINUX ntoh.cpp i sprawdź, do czego rozszerza się makro ntohl i skąd pochodzi.

Domyślam się, że masz coś głupiego w jednym z swoich nagłówków, np.

#undef ntohl 
#define ntohl(x) (x) 
+0

Te flagi są właśnie tym, czego potrzebowałem. Moje oprogramowanie wywoływało nieaktualny plik ntoh.h, który nie zawierał błędu ** NIE POWINIEN BYĆ TUTAJ ** i sprawdzania definicji ** LINUX **. Stale plik definiował ntohl (x) jako (x)! Zaktualizowałem mój plik Makefile do prawidłowego czyszczenia. Stale plik został usunięty. – Kat

Powiązane problemy