Jakub 'darkjames' Zawadzki napisał(a): > (...) > Przynajmniej tak mozna przetestowac czy external_ip i external_port > znajduja sie tam gdzie sadzimy. Chybaze serwer juz zupelnie olewa te > pola i sam sobie je znajduje. A pozostaly po prostu dla wstecznej > kompatylibnosci? :)
Na to wygląda. Poza hashem wszystko się zgadza, więc zostawmy tak jak było, mimo że w oryginalnym kliencie nie da się ustawić. > Teraz staram sie portowac moje wysniffowane dane w zwiazku z tym nowym > dcc... I tam jest taki unikatowy numerek polaczenia... Ktory dostajemy > od serwera. Ja to mam zrobione jako: unsigned char code1[8]; Mógłbyś się podzielić zrzutami, jeśli nie przesyłałeś żadnych tajnych danych? Miałem problem, żeby pobawić się nowym GG na jednej maszynie z windowsami, a co dopiero z dwoma ;) > Ale z tym problem ze ten numerek musi byc przesylany w prawie kazdym > typie pakietu. I tu jest problem. Bo imho nie warto rejestrowac tego w > jakiejs strukturce (przynajmniej nie tak od razu [1]).. A C nie oferuje > sprawdzania czy faktycznie ta tablica ktora dostal jako parametr do > funkcji ma 8 elementow... Wiec jak programista zrobi blad i przesle nam do > funkcji 5-6 znakowy ten kod, to moze sie stac cos zlego. A tez ciagle > kopiowanie przez memcpy() tych 8 znakow z parametrow do strukturek nie > wyglada zbyt ladnie... Nie za bardzo rozumiem. Jeśli programista ma przekazywać 8-bajtową tablicę, to ma przekazywać i kropka. Równie dobrze mógłby zrobić błąd w przekazywaniu hasła. > IMHO najlepiej by bylo skorzystac z uint64_t/int64_t to by oszczedzilo > troche pracy.. Ale nie wiem jak to wyglada z przenosnoscia. W tej chwili mamy warunkową obsługę zmiennych long long (też w DCC) do obliczania czasu pliku. Jeśli to będzie naprawdę konieczne, możemy zacząć wymagać uint64_t, chociaż wolałbym zrobić typedef zależny od platformy: uint64_t albo uint8_t[8]. w. _______________________________________________ libgadu-devel mailing list [email protected] http://lists.ziew.org/mailman/listinfo/libgadu-devel
