Dnia 2011-11-02, śro o godzinie 19:04 +0100, Bartosz Brachaczek pisze: > Cześć, > > Kawałek kodu w src/dcc7.c (a także kod na usługach dcc7 w > include/internal.h i src/endian.c) zależy od zdefiniowanych makr > HAVE_STRTOULL i HAVE_UINT64_T.. Tak się jednak składa, że te makra są > jedynie definiowane w config.h (include/libgadu.h.in nic o nich nie > wie), a żaden ze wspomnianych plików config.h nie includuje, więc i > kod zależny od istnienia tych makr nigdy nie jest kompilowany.
Ten kod nie jest jakoś niesamowicie istotny dla działania połączeń bezpośredni, ale i tak niezły obciach ;) > Co do HAVE_STRTOULL, wydaje mi się, że można je zastąpić > GG_CONFIG_HAVE_STRTOULL (a także GG_CONFIG_HAVE__STRTOUI64 na potrzeby > MSVC). GG_CONFIG_HAVE_STRTOULL nie jest potrzebne w żaden sposób aplikacji, więc nie pchałem tego do libgadu.h, tylko zostawiłem w config.h. GG_CONFIG_HAVE_UINT64_T też nie będzie potrzebne, dopóki nigdzie w API nie pojawi się 64-bitowa wartość. > Natomiast istnienie HAVE_UINT64_T jest dla mnie trochę dziwne, bo > przecież jest już GG_CONFIG_HAVE_LONG_LONG. Co z tym zrobić? Typ long long jest używany do operowania na liczbach, ale ze względu na różne endiany, powstała nowa funkcja gg_fix64(), która podobnie jak inne gg_fixX() operuje na typach uintX_t. Biorąc pod uwagę, że uint64_t nie musi być wcale tożsamy unsigned long long, robi się to trochę skomplikowane i nagle windowsowe API ze swoim strtoui64() zaczyna mieć więcej sensu. Sam nie wiem, co z tym zrobić na dłuższą metę, ale póki co dodałem config.h gdzie trzeba i poprawiłem #ifdef wokół funkcji gg_fix64. Pozdr, Wojtek _______________________________________________ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
