Dotaz: Prapodivne zarovnavani dat v C strukture

[neregistrovaný]

Zdravim velevazeni!

Mam takovy maly vetsi problem s Cckem a kdevelop. Pisu drobnej programek pracujici s BMP souborem. Data se nactou do nejakyho bufferu, zavola se funkce nize a ta mi z ukazatele na buffer udela ukazatel na strukturu hlavicek BMP a ty pak porovnava. Tak jak je kod napsany nize, tak take funguje - temer jak bych si pral. Struktura paradne sedi s datama ze souboru. K totalnimu blahu by mi stacilo malo: chtel bych odkomentovat ty dva radky a smazat to '+2'. Jenze tu je kamen urazu - Nefunguje to! Ten prvni short se mi v debuggeru zobrazi spravne, ale data za nim od bfSize dal jsou posunuta ne o dva, ale o ctyri bajty! Teorii Ccka a kompilatoru gcc jsem nikdy obzvlaste nestudoval, ale pod linuxem uz jsem napsal nejakych par fungujicich daemonu, slozitejsich databazovych aplikaci a hacku vseho moznyho... Ale toto vidim poprve. Netusite nahodou nekdo cimto?

typedef
struct 
{
//	short bfType;
	long bfSize;
	long bfReserved;
	long bfOffBits;
	long biSize;
	long biWidth;
	long biHeight;
	short biPlanes;
	short biBitCount;
} bmp_headers;

int getCentralPoint(char *buffer, long buf_len, long xres, long yres, long x, long y)
{
	char *poi;
	poi=buffer;
	bmp_headers *header;
	header=(bmp_headers*)(buffer+2);
//	if(header->bfType!=0x4d42) return -1;
	if(buf_len!=header->bfSize) return -1;
	if(header->bfOffBits!=54) return -1;
	if(header->biWidth!=xres) return -1;
	if(header->biHeight!=yres) return -1;
	if(header->biBitCount!=24) return -1;
...

Odpovědi

[pasmen]

No a kolik je sizeof short na tvem systemu? Proste misto 2 pouzij sizeof(short).

[neregistrovaný]

No, short by snad mel byt vsude 2B a skutecne mi to tak pise. Stejne jako long by mel bejt 4B. Nejisty byva int, proto se mu prave vyhybam. Ja mam normalni 32bitovy gentoo:

CFLAGS="-O3 -march=athlon-4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu"

Ale dylka shortu to primo neni to, co me trapi. Jako hexa cislo mi ho to ukazuje skutecne dva bajty. Horsi je, ze ta druha promenna je po odkomentovani zarovnana od ctvrtyho bajtu a ne od druhyho (resp tedy jeji offset od pocatku struktury je +4 a ne +2). A pritom, kdyz ji vynecham, tak ty dalsi dva shorty tam dal jsou spravne.

[volca]

Ty dva bajty mezi struct a long jsou kvuli tomu, aby ten long byl citelny v jednom cyklu (IMHO) Jinak jeste funguje prepinac kompilatoru --f-pack-structs nebo jak. Dylka shortu se lisi platformu od platformy, lepsi je pouzit inttypes.h a z ni int16_t, int32_t atd. i tady se vsak nevyresi problem s BIG/LITTLE endianness

[Michal Kubeček]

No, short by snad mel byt vsude 2B a skutecne mi to tak pise. Stejne jako long by mel bejt 4B.

Můžete, prosím, poskytnout referenci na místo v normě jazyka C, kde se tohle píše? Já mám třeba sizeof(long) rovno osmi…

[neregistrovaný]

No, dobre... Uznavam tedy, ze toto platilo podle nejakych starsich norem kdysi davno za 32bitova. Ve vsech trech nebo ctyrech online ucebnicich, co mam, to tak je. Ja zapomnel, ze uz existujou taky nejaky 64bitovy platformy. Ty me ovsem pro moji diplomku netrapi - jak doma, tak ve skole mam jen stary skopky... ))

[msk]

Nikdy to neplatilo podla zaidnych noriem. Bolo to ale tak bezne z dovodu vacsinovej architektury, ze to ( niektori ) ludia zacali povazovat za samozrejmost. Okrem 64 bitovych platforiem to este mozu byt 7 bitove, 24 bitove, 158 bitove a stomiliard bitove ( inymi slovami akekolvek ). Pokial chcete premapovavat binarne smetie na strukturu, pouzite (u)int_xy_t a atribut packed. Ani vyhovorka na diplomku by nemala byt zamienkou pre prasenie ( a ja byt profesor tak za taky kod vyhadzujem ).

[pasmen]

Jak to je ti povi uryvek z C Programming Language od K&R:

The intent is that short and long should provide different lengths of integers where practical; int will normally be the natural size for a particular machine. short is often 16 bits long, and int either 16 or 32 bits. Each compiler is free to choose appropriate sizes for its own hardware, subject only to the restriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short/code> is no longer than int, which is no longer than long

[petris]

No, short by snad mel byt vsude 2B a skutecne mi to tak pise. Stejne jako long by mel bejt 4B.

A na to jste prisel kde? Je to totiz pekna blbost. Jedine, co je zaruceno je, ze pro rozsahy plati short <= int <= long <= long long. Jak vidite o rozsahu v bytech tam nic neni, a proto klidne vsechny muzou byt stejne velke, treba 32bitu a je to spravne.

[valesek]

To moc nepomuze, ja jen vim, ze nejlepsi a vetsinou prenosu zdrojaku nepodlehajici vec je proste psat unsigned char[2] misto short nebo unsigned char[4] pro long, s tim jsou nejmensi problemy, v linuxu se mi toto take stalo nekolikrat, a rekl bych ze za to mohou posledni verze GCC, ktere pocitaji uz jen s 32bitovymi adresovacimi prostory a zarovnavaji vse na 32 bit, aby se jim s pametovym mistem pracovalo lip, napr struct { char x; unsigned long y }; by mela zabirat 2x32bitu v pameti pri 32bitove adresaci a bude to naskladano jako 1byte, 3byty volno, 4bytovy long, pri konstrukci struct {char x; unsigned char y[4]}; pri 32bitove adresaci to bude zarovnano asi takto 1bytex, 4byte y, 3 byty volno, dle meho je to zpusobeno upravou kompilatoru na 64bit, a univerzalnosti tohoto zpusobu kompilace, co jde vtesnat do jednoho bloku v tomto pripade 32bitu tak se tam vmestna, jinak to jde do bloku vys, muze to vyrazne urychlit praci programu, ale ma to nevyhody pri pouziti memcpy. --- omlouvam se predem pokud tady tlacham hlouposti, ale pred ctyrma lety, jak jsem zmenil pracovni misto, tak jsem se divil proc to v novem zamestani maji vse v bytech a bylo mi vysvetleno, ze je to diky zarovnavani dat v pameti na ruznych procesorech(nonPC)a z hlediska kompatibility zdrojaku je to lepsi takhle, je pravda ze pri pristupu na takovou to promennou musite pote stale pristupovat pomoci *((uint16 *) &x) apod, ale zase mam tu jistotu, ze mi to bude kompilovat spravne

[Michal Kubeček]

a rekl bych ze za to mohou posledni verze GCC, ktere pocitaji uz jen s 32bitovymi adresovacimi prostory a zarovnavaji vse na 32 bit

Ne. Mohou za to nezodpovědní programátoři, kteří na základě své zkušenosti z jedné konkrétní verze jednoho konkrétního prohlížeče (s jedním konkrétním nastavením) na jedné platformě neoprávněně usuzují, že přesně stejně se musejí chovat všechny prohlížeče na všech platformách.

[thingie]

Prohlížeče?

[Michal Kubeček]

Asi síla zvyku. Obvykle takhle dštím oheň a síru na autory webových stránek… :-)

[volca]

Dobry den, vas problem je zrejme dan optimalizaci zarovnavani poli ve struct zkuste struct obalit pomoci:
#pragma pack(push,1)
struct....
#pragma pack(pop)


[neregistrovaný]

Jo diky! Pomohlo! Nejaky takovyhle zarovnavaci direktivy jsem prave hledal v ruznych online ucebnicich a googlu, ale zatim nenasel...

[ondra]

Jo, určitě je to zarovnáváním.

Ještě jiná věc: Nevadí, že např. bfSize je někdy 32 bitů a jindy 64? Na 64 bitovém linuxu bude asi většinou long 64 bitový, na 32-bitovém je 32-bitový. Raději bych zkusil nějaký vhodný typ ze stdint.h.

[Michal Kubeček]

Specifikace jazyka neříká nic o tom, jak budou jednotlivé položky struktury zarovnány v paměti. To, co požadujete, se dá u některých překladačů vynutit speciální direktivou, ale obecně to zařídit nelze. Musíte si uvědomit, že existují i platformy, kde procesor neumí číst 32-bitové slovo z adresy, která není dělitelná čtyřmi (a i tam, kde to jde, je to často pomalejší).

Navíc si zaděláváte na problémy s kompatibilitou už tím, že položky deklarujete jako short a long, což jsou datové typy, o jejichž velikosti nevíte obecně vůbec nic kromě toho, že sizeof(long) >= sizeof(short). Takže ta vaše ukázka kódu je odstrašujícím příkladem toho, co nazývám empirickým programováním - zkusil jste to přeložit na jednom počítači jedním překladačem s jednou variantou parametrů a fungovalo to, takže usuzujete, že to musí fungovat všude.

[neregistrovaný]

Jasne, pro prenositelnost urcite bastl. Vychazi to ale z predpokladu 32bitove platformy a ze tam ten kod taky zustane. Snazil jsem se prave jen vyhnout moznym problemum s velikosti int.

Ale pri te prilezitosti by me tedy zajimalo, jak by se to dalo co nejvic koser napsat univerzalneji. Rad se necemu novemu priucim... Preci jenom 64b pocitacu asi mozna ubyvat nebude...

[happy barney]

fukncie, nezávislé na byte-order/sizeof cieľoveho stroja

[Tom K]

viz stdint.h
u_int32_t a jemu podobne datove typy

[happy barney]

btw, mimo aktuálny problém by bolo vhodné vás upozorniť na problém big-endian v little-endian

riešenie oboch je rovnaké:

header->bfxxx = read_int16 (buffer);
header->bfyyy = read_int64 (buffer);

C vraví iba to, že short nie je väčší ako int, long nie je menší ako int, a int má minimálne 32 bit.

[valesek]

a na 16bit procesorech je int roven 16bit

[happy barney]

jj, malo byť long, nedávam si pozor
ale to, že je short min 16bit, to som už dávno zabudol

[Tom K]

tusime.
v C neni nikde receno, ze struktury se zarovnavaji na velikost promenne, takze chytry kompilator to zarovna tak, aby se to CPU lepe cetlo. pokud chces mit strukturu zarovnanou, nech strycka googla hledat: __attribute__((packed)).