ezt most írták

"óriási flash két óra után rájönni, hogy a program, amit írtál, ami lefordul warning nélkül, azért nem működik helyesen, mert a ciklusmagban létrehozott lokális változó hamarabb megszűnik, minthogy feldolgozná a ciklusmagban meghivott eljárás, aminek paraméterként átadtuk, és csak emiatt kénytelen vagy a meghivott eljárás elején (mert akkor még épp létezik a változó) új helyet foglalni neki, és átmásolni oda..."

hát mit lehet erre mondani? :)

( NagyZ v | 2011. 02. 01., k – 14:47 )

hogy aki irta, nem ert hozza?:)

vagy hogy egyeb nyelvekben (ada pl) lokalis konstans a ciklusvaltozo, es nem lehet elrontani?:)

nincs C-hez szokva :)

a ciklusmagban egy pointerben összerakott két stringet, és ezt adta paraméterként egy eljárásnak, és az eljárás után a ciklusmagban már fel is szabadította a pointert, így az a meghívott eljárásban csak az első pár sor után már üres volt..:) na bemásolom már:

while ((dp=readdir(dir)) != NULL) {
char *tmp=malloc((strlen(dir_path)+strlen(dp->d_name)+1)*sizeof(char));
memcpy(tmp,dir_path,strlen(dir_path)+1);
strcat(tmp, dp->d_name);
write_path(dp->d_name,tmp);
free(tmp);
}

a write_path eljárásban egy-két sor után már nem volt tartalma a tmp-nek :)

----------------
...jönnek a gépek, a szemükben nincs harag...

subscribe.
Kíváncsian várok egy logikus magyarázatot, hogy kerek legyen az egész.
Szerintem is előbb vissza kellene térnie a függvénynek, és csak utána szabadulhatna fel a lefoglalt memória.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 13.1 | 2.6.34.1-janos

Ez nekem is fura, bar ilyen kis ertekekhez eleg szokott lenni a stack, de ez meg nem magyarazat a hibajelensegre.

A dir_path az honnet jon? nem strlen(dp->d_name) +1 meretu buffert kene lefoglalnod?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem.
Gondolom van egy ilyen "/home/" jellegu konyvtara, ahol epp all. Ez a dir_path, es epp itt all. Ezen belul vannak ilyen "nyos", "hrgy84" meg hasonlo file/konyvtarnevei, ezekbol csinal a tmp valtozoba osszeconcat-olt stingeket ("/home/nyos", "/home/hrgy84"). Szoval hossznak az egyik hossza+masik hossza+1 a lezaro nullanak. Persze csinalhatna egy malloccal, ha tudja a rendszer maximalis pathmeretet (es nem tul nagy), vagy ha nem hosszabb az elozo leghosszabbnal, akkor is elferne.. ill. feleslegesen masolja oda mindig az elso stringet, mert az mindig ugyanaz (eleg lenne a ciklus elott elokesziteni, es utana ciklus utan egy free). A dir_path hossz szinten egyszer lekerdezheto es tarolhato. Szoval lehetne gyorsabban, lehetne szebben, de ez nem magyarazza a hibajelenseget, es nem is hiszem, hogy futasidoben lenyeges javulast jelentene, ill. hogy a kodreszben sok idot toltene a proci (mert itt ugyis a lemezsebesseg szamit, meg a filerendszer).

Ez persze csak akkor igaz, ha a write_path nem szurja el a valtozo tartalmat - amit viszont ugyis ki kell javitania.

--
Auto correct can go straight to He'll.

Valóban nem túl szép, és gyorsítani is lehetne, bár ahogy te is mondod, itt a fileIO a sarkallatos pont mindenképpen, és szerintem azért ilyen szétszórt a kód, mert már 28x átírta kínjában, ugyanis nem találta a hibát..:)

A write_path egy tömbben eltárolja az útvonalat, plusz ki is írja a standart outputra. Semmi olyat nem csinál, ami befolyásolhatná a paraméter értékét. Két paramétere van, az egyik egy könyvtár teljes útvonala (pl /home/pisti) a masik pedig a könyvtár "neve" (példánk esetében ez "pisti") na és ezt a két dolgot egy structokból álló tömbben tárolja. Viszont az eljárásban a tömböt dinamikusan átméretezi, lehetséges, hogy az ottani malloc kavarja meg a dolgot...

A forrást megkereshetem ha nagyon fontos, de gondolom simán elképzeltek egy ilyen eljárást.

----------------
...jönnek a gépek, a szemükben nincs harag...

Ez eltüntet igy egy csomo memoriat.


temp=malloc(usercount*sizeof(userdata));
temp=users;

Foglalas utan azonnal felülirjuk a temp-et. A lefoglalt memoriaterületre nem mutat mar semmilyen mutato, igy azt mar soha semmi nem eri el. Ezt minden egyes függvenyhivaskor megcsinalja, tehat lepesenkent elszivarogtatunk usercount*sizeof(userdata) memoriat. Nem tudom, hogy köze van-e a keresett problemahoz, de ez igy nagyon nem jo.
Szerintem itt egy sima realloc() jo lenne. Probald ki ugy, hatha...

az users változó egy tömb, ami az alábbi "userdata" struktúrákból épül fel, és minden users változóval kapcsolatos változtatást a write_path végez.

typedef struct {
char *name;
char *fullpath;
int id;
} userdata;

----------------
...jönnek a gépek, a szemükben nincs harag...

akkor mutatok egy peldat hogy pl hogy lehet a users -el elrontani az egeszet: 


  1 struct userdata {
  2     int x;
  3 };
  4 
  5 
  6 int main()
  7 {
  8     int usercount = 2;
  9     struct userdata user;
 10     struct userdata * users = &user;
 11     int y = 11;
 12     int i;
 13 
 14     for (i = 0; i < usercount; i++)
 15         users[i].x = 5;
 16     printf("%d\n", y);
 17     return 0;
 18 }

es azt irja ki hogy 5. Pedig az y-t "sehol nem valltoztattuk"