KOMPILACE, GCC PODRUHE

[Jan Kurik]

> Odesilatel: Zdenek Pizl, Czech Agriculture University, Prague <pizl na max.af.czu.cz>
> 
> Mozna jsem trochu off topic a unavnej ale
> 
> podival jsem se na knihovny co to pouziva a kde to presne vytuhne :
> 
> /lib/libc.so.5.3.12
> /lib/ld-linux.so.1
> 
> a ted mi nebudete verit, tuhne to na radku return(ret), kde ret je signed
> long definovany na zacatku funkceto se mi zda naprosto absurdni, zvlast
> kdyz to vytuhne v __libc_free(), uznavam ze  se tam s vysokou
> pravdepodobnosti volaji destruktory mych slavnych objektu, kde si hraju s
> alokacema (odalokovaT NAALOKOVANY POLE CHAR jeste svedu:-), ale to by pak
> muselo padat i pod WIN$hitem a nebo DOSem,
> kompilator Watcom 10.5 C/C++ ale tam ani nahodou ??
> 
> tak teda nevim
> 

	Presne tohle mi to delalo pod Win a nekdy po DOGsem. Nakonec jsem prisel na to, ze se mi to stane pokud si alokuju kus pameti a pri pouzivani zapisu dal nez kam jsem to alokoval. Napr.:
/***/
char * X = (char *) malloc(10); /* Alokuju 10 Byte */
....
*(X + 10) = '\0'; /* Zapisu na 11-ty Byte */
....
free(X); /* Ale az tady to spadne */
/***/

	Chvili mi trvalo, nez jsem na to prisel, ze to nespadne pri zapisu, ale az pri uvolneni. U Linuxu jsem zatim takovy problem nemel, ale taky pod nim programuju relativne malo. Zkuste se treba podivat, jestli nekde nezapominate na alokovani pameti o 1B vetsi, nez je delka retezce ( na znak '\0' ), coz je treba moje casta chyba :-).

Jan Kurik