On May 6, 5:39 am, "Wojciech \"Spook\" Sura"
<wojciech.sura_no@spam_poczta.medi.com.pl> wrote:
> Dnia 03-05-2011 o 01:14:36 Andrzej Jarzabek <a...@g...com>  
> napisał(a):
>
> > On 02/05/2011 22:06, f...@W...gazeta.pl wrote:
> >> czyli w skrocie ->  ZAPCHANIE sobie tablicy (przez bledy w poodznaczaniu
> >> flag) to nie WYCIEKI
>
> > To są wycieki.
>
> Kwestia definicji. Program nadal może dostać się do "zapchanych" elementów  
> tablicy jawnie ją indeksując.

Co to znaczy "program może"? Jeśli z algorytmu programu wynika, że
nigdy się do tego elementu nie dostanie, to przecież nie może. Jeśli
zmienimy mu kod to owszem, będzie mógł, ale to samo dotyczy dowolnego
programu z wyciekami: odpowiednio zmieniając kod można doprowadzić do
tego, że wycieków nie będzie.

> Ba, można banalnie łatwo napisać odśmiecacz,  
> który z powrotem odzyska nieużywane rekordy.

Nie można, jeśli nie jesteś w stanie określić, które rekordy są w
danym momencie używane.

Poza tym fakt, że można napisać odśmiecacz nie znaczy, że program
_bez_ tego odśmiecacza nie ma wycieków.

Poza tym weź pod uwagę, że struktury sterty, z których korzystają
malloc i free też raczej trzymają (a przynajmniej mogą trzymać)
namiary na każdy z bloków zaalokowanych przez malloc, niezależnie od
tego, czy kliencki kod otrzymane uchwyty (wskaźniki) jeszcze gdzieś
trzyma, czy nie. Dla klienckiego kodu te struktury są rzecz jasna
niedostępne, ale kod funkcji malloc czy free może z powodzeniem czytać
i modyfikować te struktury, które odpowiadają "wyciekniętej" pamięci.
A przecież kod biblioteki i jej struktury danych stają się częścią
programu po zlinkowaniu.

> Tylko że Firowi _cały czas chodzi o fizyczne wycieki_, a nie o logiczne,

Fizyczne wycieki to możesz mieć najwyżej w komputerze chłodzonym
wodą. :)
 
> związane z konstrukcją programu. Tobie zaś chodzi o logiczne (w których  
> zawierają się fizyczne) i dlatego obaj kłócicie się bezproduktywnie.

Och, jeśli zdefiniujesz "fizyczne wycieki" jako "wycieki spowodowane
przez użycie malloc", to naturalnie takich wycieków nie ma w
programie, który nie używa malloc. Mogą być w nim wycieki w sensie
wycieki tak w ogóle, w którym to sensie zawierają się oczywiście
również wycieki spowodowane użyciem malloc.

Dwa pytania: wiedząc, jak dana implementacja biblioteki libc
implementuje stertę, w zależności od interpretacji możliwe może być
dostanie się do dowolnych wcześniej zaalokowanych przez malloc bloków,
w sposób nieprzenośny (generalnie czytając metadane np. zajmujące ileś-
tam bajtów przed otrzymanym z malloc wskaźnikiem). Czy sam fakt, że
jest to możliwe dla jakiejś implementacji malloc powoduje, że dowolny
program (również taki nie korzystający z tej możliwości) używający tej
implementacji malloc nie ma wycieków?

Drugie pytanie: załóżmy, że zrobię sobie bibliotekę libmyalloc, która
udostępnia funkcje my_alloc() i my_free(). Ich specyfikacja jest taka
sama jak malloc i free, tylko że zawierają własną implementację
sterty, która - tak się składa - przechowuje w swoich strukturach
każdy blok zaalokowany przez malloc. Jeśli więc zechcę, mogę sobie
napisać w libmyalloc funkcję, która iteruje sobie po wszystkich
zaalokowanych blokach. Mógłbym też udostępnić klientowi funkcje
my_first_allocated_block() i my_next_allocated_block() pozwalające
klienckiemu kodowi przespacerować się po wszystkich zaalokowanych
blokach - ale chwolowo załóżmy, że tego ne robię.

Więc w kolejności: jeśli napiszę program korzystający z libmyalloc,
który w pewnym momencie wykonuje gdzieś my_alloc i nigdy dla tych
zaalokowanych bloków nie robi my_free, co z czasem prowadzi do
zapchania sterty zarządzanej przez libmyalloc, to jest wyciek, czy nie
ma wycieku?

A jeśli dodam _przy tym samym programie klienckim_ do biblioteki
libmyalloc funkcje my_first_allocated_block() i
my_next_allocated_block(), to coś się zmieni? Zauważ, że kod kliencki
oczywiście z tych funkcji nigdy nie korzysta, bo przeciez przed chwilą
ten sam kod linkował się z biblioteką bez tych funkcji. Są wycieki,
czy ich nie ma?