Prvo jedan savet: da bi se lak�e �itala struktura iz nekog hex editora, dodaj 4 rezervisana bita posle 4 polja po jedan bit (npr. unsigned int rez:4; ), ili prebaci ta 4 polja na kraj strukture. Ovo se mo�e re�iti i dodeljivanjem podatku block, umesto :8 du�ine, tipa unsigned char (zna�i unsigned char block;) - tada kompajler automatski poravna po�etak block podatka na 8 bita.
U ovakvom slu�aju je mogu�e �itati strutkturu veoma jednostavno iz hex editora. Tada bi fajl izgledao ne�to kao (X stoji tamo gde mo�e sva�ta biti):
"xXbx17x35x61x00xXXxXXxXX"
Prvi bajt, i to njegova 4 "low-order" bita bi sadr�ala svaki po odgovaraju�u vrednost (b=11=1+2+8, zna�i bitovi 0, 1 i 3 - gas, air i wash). Slede�i bajt bi sadr�ao vrednost block, a zatim bi sledilo 6 bajtova sa vredno��u "5a" (ovo zna�i null-terminated string - tri bajta, 0x35, 0x61, 0x00), a ostatak tih 6 bajtova bi bio popunjen �ubretom iz memorije (zbog toga i razlika izme�u DOS i Linux ispisa).
Preporu�en oblik strukture:
Code:
struct proba
{
unsigned int gas : 1; /* 1 bit */
unsigned int air : 1; /* 1 bit */
unsigned int dish : 1; /* 1 bit */
unsigned int wash : 1; /* 1 bit */
unsigned char block; /* 8 bita */
unsigned char lot[6];
} input;
Ukoliko nije mogu�e ovako izmeniti sastav strukture, ona se mo�e i��itati na slede�i na�in.
Citat:
Code:
"x7bxf1x35x61x00xd9x00x40" (u Linux-u)
"x7bx01x35x61x00x01x00x00" (u DOS-u)
U prvom bajtu razdvojimo njegove high- i low-order delove od po 4 bita: 0x7 i 0xb. Na isti na�in kao i prethodno, 0xb se dekodira na gas, air i wash uklju�ene, a dish isklju�en. Ali sada 0x7 predstavlja low-order deo od 4 bita od polja block, a high order deo od 4 bita polja block se nalazi u drugom bajtu, na prva 4 bita - 0x1. Razlika izme�u Linux i DOS fajla ne postoji, po�to se high-order 4 bita na Linux-u puni �ubretom, a u DOS-u se nulira (ili ne??), �to ide u prilog dobroj optimizaciji GCC-a pod Linux-om.
Dalje, po�to char tip zahteva poravnavanje na 8-bita (njegova veli�ina), tih 4 high-order bita u drugom bajtu se ne koristi u svakom slu�aju. Zatim slede karakteri 0x35 ('5') i 0x61 ('a'), kao i null karakter (0x0). Ostala tri bajta su �ubre.
Prema tome, da bi uspe�no i��itao ovakav fajl iz hex editora, potrebno je dovoljno brzo baratati jednostavnom hex aritmetikom, kao i lako pretvarati hex brojeve u binarne (a to se lako i radi, zato se oni i koriste).
Toliko.
Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu.