On Thursday, December 3, 2015 at 5:29:03 PM UTC+1, Maciej Sobczak wrote:
> > Jakie triki? W ogóle nie można rozpoznać na podstawie samych
> > danych w jakim formacie są zakodowane.
>
> Przecież nikt nie każe rozpoznawać formatu na podstawie danych. O ile zrozumiałem
nawiązanie do protokołów sieciowych, to format jest zwykle znany z góry.
Jeśli przyszły dane w formacie znanym na podstawie protokołu, to trzeba
napisać konwersję zgodną z danym formatem. Rozmowa, w kontekście znanego
protokołu, zarówno o kopiowaniu bit po bicie, jak i o kopiowaniu z
użyciem operatora konwersji (int), nie ma sensu. Rozmawialiśmy o
szczególikach, typu:
1) można się przejechać na big/lit endian
2) najpierw memcpy, potem operator rzutowania
3) różny padding w strukturach
4) różny rozmiar inta na różnych platformach lub wersjach programu.


> > Rozmawiamy oczywiście o
> > zgodnych formatach.
>
> Co to znaczy zgodnych formatach? Jest jeden format (zwykle znany) i trzeba go
zdekodować na poszczególne pola (albo odwrotnie - spakować ze znanych wartości pól).
Te triki z pragmą, polami bitowymi albo rzutowaniem wskaźników to są złe rozwiązania.

Dlaczego złe? Jeśli ktoś wysyła tablicę struktur wyrównanych do 1 bajta, to
sytuacja ma się odwrotnie niż pisałeś: Jedynie przez przypadek odczyt
zadziała na strukturach wyrównanych do 4 bajtów. Dlatego są złe, że nie
używa się przenośnych funkcji do wysłania i odebrania każdego pola? Owszem
to drobna wada. Ale wyobraź sobie, że ktoś pisze program tylko na windows i
tylko na x86, ma strutkurę z 20ma polami i zamiast napisać
write( &strukt , sizeof(strukt) , file )
pisze 20 razy:
write( unwersalny_format_int( strukt.pole1 ) , uniwersalny_rozmiar_int( strukt.pole1
) , file );

Zgodzę się, że kod z memcpy jest ryzykowny, ale po pierwsze ryzyko to pojawia
się tylko w określonych sytuacjach, a aktywne unikanie tego ryzyka zajmuje
czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.


Pozdrawiam