Zasto ovo radi?!

[ Goran Arandjelovic @ 04.09.2005. 10:33 ] @

Mislim da ovo ne bi smelo da radi...sta se ovde desava? Da li je ovo ovako samo sa prostim tipovima?

Code:

int *x,i;
x = new int[1];
for(i=0;i<1000;i++){
x[i] = 7;
}
cout << x[999];

Imam gcc3.3.4 ...

[ X Files @ 04.09.2005. 11:17 ] @

Dakle, u primeru koji si naveo treba da stoji:

Code:

x = new int[1000];

i na kraju:

Code:

delete [] x;

... da bi primer bio ispravan.

Pretpostavljam da ti je cudno to sto si rezervisao memoriju za samo 1 int, a
uspesno si pristupio memoriji i dodelio vrednosti za svih 1000, i na kraju sve to
verifikovao ispisom...

To je u C/C++ legalno (obican pointerski pristup), ali naravno nije dobro, jer kod
ozbiljnijih primera lako mozes da *unistis* (overwrite ili over-run) neki drugi objekat.

To je ono protiv cega se pored ostalog bori .NET i 'managed' kod.

U praksi to znaci da tvoj kod u startu moze i da proradi, a da u nekoj kasnijoj fazi
pukne i da pojma nmas zasto se to desilo...

U medjuvremenu pogledaj ovaj primer i probaj da predbidis rezultat:

Code:

   int *x,*y, i;
   x = new int[1];
   y = new int[1];

   y[0] = 8;

   for(i=0;i<1000;i++){
     x[i] = 7;
   }
  ShowMessage( x[999] );
  ShowMessage( y[0] );

  delete [] x;
  delete [] y;

... a posle probaj da zamaskiras petlju.

P.S. Dodatak:

Mene je slicna stvar dugo 'mucila' jer jedan od mojih NT servisa nikako nije hteo da
radi (stabilno) na NT4 Workstation, a radilo se (karikirano) o ovome:

char a[1000]
a[1000] = 'x';

... servis se non-stop po automatizmu zaustavljao kad doje do ovoga.

_{[Ovu poruku je menjao X Files dana 04.09.2005. u 12:21 GMT+1]}

_{[Ovu poruku je menjao X Files dana 04.09.2005. u 12:28 GMT+1]}

[ Goran Arandjelovic @ 04.09.2005. 12:51 ] @

Bez provere pretpostavljam da ce i y[0] postati 7... Ispravi me ako gresim...

[ X Files @ 04.09.2005. 12:52 ] @

Da ! :)

[ Goran Arandjelovic @ 04.09.2005. 12:54 ] @

Ajoj...proverio sam kod... Ovo zaista moze da bude katastrofalno.

I da... sa nekim klasama se to ne desava... da je u pitanju bio neki moj objekat u onom mom primeru... to se ne bi desilo...prijavio bi run time gresku.

_{[Ovu poruku je menjao Goran Arandjelovic dana 04.09.2005. u 13:58 GMT+1]}

[ Giga Moravac @ 05.09.2005. 13:05 ] @

A zasto ovo radi na linux-u, a na XP program(i) pucaju (borland free kompajler)?

[ X Files @ 05.09.2005. 17:39 ] @

Kod mene (Borland C++Builder) takodje su primeri radili... A mislim da je odgovor
na to pitanje - PONAŠANJE JE NEDEFINISANO ZA TAKAV KOD. Može slučajno da
radi, ali kada ima puno više alociranih objekata - program definitivno puca...

[ rumpl @ 05.09.2005. 21:05 ] @

Moje skromno mislljenje...

Ovakve stvari sam vidjao kod nekih buffer overflow exploita. Stvar je u tome sto razne
arhitekture drugacije slociraju buffer memoriju. Pa cak i razni OS-ovi. Znam da MAC to
stvarno dobro radi, ima ogromni prstor rezervisan za stack.
Ako se neko igra sa C-om sigurno je video da ako ima char* koji mallocuje na 1024, biffer overflow
se javlja mnogo kasnije, kod mene je bilo 1036 sa gcc3.* a sad sa gcc4.0 je 1044, ako se dobro secam. Znaci. sasvim je "normalno", ali predpostavljam da ne vazi za objekte jer je alociranje drugacije.
Nadam se da sam bio jasan, nisam mnogo citao odgovore od drugih, tako da ako je neko vec
odgovorio kao ja, ili ako sam skrenuo sa teme izvinjavam se.

Pozdrav

[ itf @ 06.09.2005. 01:28 ] @

Napravio sam simulaciju u Assembleru. Sve je ok dok se adresiraju slobodne memorijske lokacije. Ako se naleti na neku zazuzetu tada program puca. Zbog toga se i vrši dinamička (statiča) alokacija da bi te memorijske lokacije bile 100% slobodne, a dok će npr. funkcija realloc pri realociranju memorije ako naleti na zauzetu mem. lokaciju cijeli mem. blok koji treba biti realociran prekopirati na drugo mjesto da zaobiđe ovu zauzetu mem. lokaciju i spriječi pucanje programa.

_{[Ovu poruku je menjao itf dana 06.09.2005. u 02:52 GMT+1]}