> > - leaki (wycieki)
> > - zwis (hang)
> > - crash to desktop
> > - crash systemu
> >
> > na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;
>
> Te powyzsze to najprostsze do naprawienia :)
> Sa znacznie gorsze np
> program zle policzy kapuste i firma pojdzie z torbami
> program zle policzy natezenie promieniowania w urzadzeniu do naswietlania
> RTG
> program zle policzy parametry lotu rakiety i ta p..lnie w jakies
> paromilionowe miasto
> itd
> Czyli - ogolnie - program zle dziala :)
>

JESTEM WKURZONY, jestem jakis ekstremalnie wkurzony, zle sie czuje,
robota (bo mam cos do zrobienia) tez zle idzie, czuje sie struty -
chyba musze isc przeczekac


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Mon, 2 May 2011 15:32:10 +0000 (UTC), Marcin Kwiatkowski
<m...@m...com> wrote:

>D
>
>G.J. Myers, "Projektowanie niezawodnego oprogramowania." I nie Pascal, a
>Algol, na pewno z elementami Fortranu. Mimo że wydana dość dawno temu - polecam.

Proponuje ksiazke bardziej na czasie:

Fatal Defect: Chasing Killer Computer Bugs, Ivars Peterson, 1996

chociaz jest bardziej "anegdotyczna" niz Myers

Znanym specem od niezawodnosci jest David Parnas. Dostepny jest zbior
jego prac

Software Fundamentals: Collected Papers by David L. Parnas,
Daniel M. Hoffman, David M. Weiss

wydany rozniez po polsku

A.L.

do góry

fir <f...@g...SKASUJ-TO.pl> napisał(a):

>
> > > - leaki (wycieki)
> > > - zwis (hang)
> > > - crash to desktop
> > > - crash systemu
> > >
> > > na pewno mozna cos dorzucic, poszerzyc i pouszczegolawiac ta liste;
> >
> > Te powyzsze to najprostsze do naprawienia :)
> > Sa znacznie gorsze np
> > program zle policzy kapuste i firma pojdzie z torbami
> > program zle policzy natezenie promieniowania w urzadzeniu do naswietlania
> > RTG
> > program zle policzy parametry lotu rakiety i ta p..lnie w jakies
> > paromilionowe miasto
> > itd
> > Czyli - ogolnie - program zle dziala :)
> >
>
> JESTEM WKURZONY, jestem jakis ekstremalnie wkurzony, zle sie czuje,
> robota (bo mam cos do zrobienia) tez zle idzie, czuje sie struty -
> chyba musze isc przeczekac
>
>

OK, juz dziala,
we may continue

no farmakology is involved ;-) [ po prostu z doswiadczenia
wiem ze jak mam 'kryzys' (a miewam okresy maskrycznego rozwalania,
cos jakby poczucia dysharmonii ) to musze przeczekac

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2011-05-02 17:32, Andrzej Jarzabek pisze:
> On Mon, 2 May 2011 11:08:59 +0000 (UTC), " fir" <f...@W...gazeta.pl>
> wrote:
>> statyczny c to c bez mallocow - c wylacznie ze statycznymi tablicami
>
> Przecież w takim czymś również można mieć leaki, tylko trudniej je znaleźć.
Mozna tez wierzyc, ze sie nie ma ...

do góry

Jacek Czerwinski <...@...z.pl> napisał(a):

> W dniu 2011-05-02 17:32, Andrzej Jarzabek pisze:
> > On Mon, 2 May 2011 11:08:59 +0000 (UTC), " fir" <f...@W...gazeta.pl>
> > wrote:
> >> statyczny c to c bez mallocow - c wylacznie ze statycznymi tablicami
> >
> > PrzecieĹź w takim czymĹ&#65533; rĂłwnieĹź moĹźna mieÄ&#65533; leaki, tylko
trudniej je znal
> eĹşÄ&#65533;.
> Mozna tez wierzyc, ze sie nie ma ...
>

nie mozna, nie mozna miec leakow jak sie nie alokje ani dealokuje nawet
bita pamieci spoza statycznej puli, mozna za to w takim ststycznym c
pisac po nie swojej pamieci albo nadpisywac niepoprawnie wlasna -
literalnie nigdy nie zastanawialem sie czy mozna i warto cos z tym
zrobic - w c okropnie imponuje mi ten jego cyrkowy akrobatyczny
'lightweight'

--
((ooh la la - slucham sobie dobrej plyki starej kapelki
crash test dummies))



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@W...gazeta.pl> napisał(a):

> Jacek Czerwinski <...@...z.pl> napisał(a):
>
> > W dniu 2011-05-02 17:32, Andrzej Jarzabek pisze:
> > > On Mon, 2 May 2011 11:08:59 +0000 (UTC), " fir" <f...@W...gazeta.pl>
> > > wrote:
> > >> statyczny c to c bez mallocow - c wylacznie ze statycznymi tablicami
> > >
> > > PrzecieĹź w takim czymĹ&#65533; rĂłwnieĹź moĹźna mieÄ&#65533; leaki, tylko
> trudniej je znal
> > eĹşÄ&#65533;.
> > Mozna tez wierzyc, ze sie nie ma ...
> >
>
> nie mozna, nie mozna miec leakow jak sie nie alokje ani dealokuje nawet
> bita pamieci spoza statycznej puli, mozna za to w takim ststycznym c
> pisac po nie swojej pamieci albo nadpisywac niepoprawnie wlasna -
> literalnie nigdy nie zastanawialem sie czy mozna i warto cos z tym
> zrobic - w c okropnie imponuje mi ten jego cyrkowy akrobatyczny
> 'lightweight'
>
> -
> ((ooh la la - slucham sobie dobrej plyki starej kapelki
> crash test dummies))
>
>
>

wogole to moze warto przypomniec w tym miejscu moj osobisy wynalazek tj
slowko kluczowe realloc (jedna z proponowanych poprawek do c)


w statycznym c ze slowkiem realloc tez byloby trudno o leaki
mimo ze juz nie byloby w tym sensie statyczne, ststyczna bylaby
ilosc tablic ale ich rozmiary moglybybyc zmieniane dynamicznie jak
suwakiem, <<smutne jest to ze te realloki trwaja tak masakrycznie
dlugo, (ooh la la), aczkolwiek raz myslalem ze pewnym bledem jest
byc moze ze nie podaje sie wiecej info malok-machinerii, np
gdyby podawac "myMem = mallok(100, 10000)" gdzie pierwszy
parametr okresla realnie zaalokowana pamiec a drugi przypuszczalny
maksymalny lymit dla reallokacji to malokmaszyna moglaby zarezerwowac
miejsce na idealne reallloki>>



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 02.05.2011 20:56, f...@W...gazeta.pl pisze:
>
> wogole to moze warto przypomniec w tym miejscu moj osobisy wynalazek tj
> slowko kluczowe realloc (jedna z proponowanych poprawek do c)
realloc istnieje i ma się dobrze.

A nikt Ci nie zabroni przecież zamiast:
int a[100];
pisać
int *a=malloc(100*sizeof(int));
a potem
a=realloc(a,1000);

--
Pozdrawiam
Michoo

do góry

W dniu 02.05.2011 20:37, f...@W...gazeta.pl pisze:
> nie mozna, nie mozna miec leakow jak sie nie alokje ani dealokuje nawet
> bita pamieci spoza statycznej puli
Ależ można, można - starczy, że pobierzesz coś z puli a potem nie
zwrócisz. W momencie gdy używasz puli jedyna różnica w porównaniu do
malloc/free/realloc to to, że tracisz czas na pisanie samemu alokatora i
ryzykujesz popełnienie w tym błędów.

--
Pozdrawiam
Michoo

do góry

Michoo <m...@v...pl> napisał(a):

> W dniu 02.05.2011 20:37, f...@W...gazeta.pl pisze:
> > nie mozna, nie mozna miec leakow jak sie nie alokje ani dealokuje nawet
> > bita pamieci spoza statycznej puli
> Ależ można, można - starczy, że pobierzesz coś z puli a potem nie
> zwrócisz. W momencie gdy używasz puli jedyna różnica w porównaniu do
> malloc/free/realloc to to, że tracisz czas na pisanie samemu alokatora i
> ryzykujesz popełnienie w tym błędów.
>

o ile pamietam to z niektorymi powinienem nie rozmawiac (poki nie
przywala glowami ze trzy razy w sciane) - zwlaszcza ze rozmowa nie
zapowiada sie ciekawie bo znowu troche wieje zombie-mysleniem -
ale pominawszy ten problem chwilowo:

nie mozna, jesli taki statyczny program zarezerwowal zainicjowal np 2
megabajty 200 kilo statycznej pamieci to chocby nie wiem co ani nie zwroci
kilobajta do systemu ani nie zabierze ani bajta - nie ma leakow

co do alokatorow to alokatory czesto nie sa potrzebne bo wiele
zjawisk w programowaniu dotyczy dzialan na stalej liczbie obiektow

zas jesli mam wewnetrzny alokator na statycznej tablicy to jesli nie
zaznacze (np po zestrzeleniu samolotu) ze dany rekord z danymi
jest nieuzywany i gotowy do nadpisania, to nie jest to leak tylko
wewnwtrzny blad w programie (pamiec sie nie urywa tylko jest
blednie pooznaczana jako zajeta) - bardzo gruby: nie bardzo podobny
do mem-leaka i analogiczny do zlego poustawiania pol w strukturach
- takie rzeczy sie raczej wogole nie zdarzaja, (tj trudno tego nie
zauwazyc), sa to wewnerzne bledy w kodzie (bledy stanu danych, analogiczne
np do zlego ustwienia pozycji samolotu albo nadaniu mu zlego koloru) i
taki maja charakter, jest to absoutnie cos zupelnie innego niz to
co nabralo odrebnego abstrakcyjnego znaczenia jako 'leak' (a co
oznacza ze gdzies sie urwal kawalek ramu nie wiadomo gdzie nie
wiadomo co, zgubiony ram nawet stracil swoja referencje bo ta ktora
kiedys go trzymala juz wskazuje na cos innego)

takie borykanie sie z owymi leakami (odpadnietymi kawalkami ramu)
to doswiadczenie _absolutnie_ mi w c nie znane, niemozliwe i po prostu
nie wystepujace








--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> zas jesli mam wewnetrzny alokator na statycznej tablicy to jesli nie
> zaznacze (np po zestrzeleniu samolotu) ze dany rekord z danymi
> jest nieuzywany i gotowy do nadpisania, to nie jest to leak tylko
> wewnwtrzny blad w programie (pamiec sie nie urywa tylko jest
> blednie pooznaczana jako zajeta)
Na tym polega leak - pamięć nie jest używana a jest oznaczona jako
zajęta (tylko w libc a nie bezpośrednio w twoim kodzie).

> - bardzo gruby:
Oj tak. Wycieki pamięci to bardzo grube błędy.

> - takie rzeczy sie raczej wogole nie zdarzaja, (tj trudno tego nie
> zauwazyc)
Takie błędy bardzo ciężko zauważyć. Jeżeli np po wyleceniu za planszę
samolot jest z niej usuwany, ale nie zwalnia miejsca w statycznej
tablicy samolotów to zauważysz to dopiero po dłuższym czasie i w
kompletnie innym miejscu (przy próbie utworzenia nowego samolotu).


> , sa to wewnerzne bledy w kodzie (bledy stanu danych,
Właśnie. Pozbyliśmy się wskaźnika, który jest nam ciągle potrzebny, bo
wskazuje na dane.

> co nabralo odrebnego abstrakcyjnego znaczenia jako 'leak' (a co
> oznacza ze gdzies sie urwal kawalek ramu nie wiadomo gdzie nie
> wiadomo co, zgubiony ram nawet stracil swoja referencje bo ta ktora
> kiedys go trzymala juz wskazuje na cos innego)

Myślisz zbyt meta-magicznie-niskopoziomowo - wyciek zasobu (nie musi to
być pamięć - mogą być deskryptory plików, sockety, muteksy, etc) jest
wtedy gdy po użyciu zapominasz odłożyć zasób na swoje miejsce. Czy to
będzie close(fd), czy to będzie free(ptr), czy to będzie
tablica_samolotow[x].wolny=true - nie ma znaczenia.

Jedna istotna różnica jest taka, że przy statycznych tablicach to trochę
szybko wychodzi, ale wystarczy wypisywać przy każdym malloc/free
komunikat, żeby prosto znaleźć co nei zostało zwolnione. Albo użyć
przeznaczonych do tego narzędzi jak np valgrind.


> o ile pamietam to z niektorymi powinienem nie rozmawiac (poki nie
> przywala glowami ze trzy razy w sciane)
Ja z Tobą też miałem nie gadać póki nie zaczniesz leczyć depresji, ale
że piszesz w okolicy sensu to toczę tę pogawędkę, więc 1:1.

--
Pozdrawiam
Michoo

do góry