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
