jak chwile sie nad tym zastanowilem (mimo
zlego samopoczucia) to wyszlo mi ze bledy
mozna podzielic na uchwytne (uchwycone)
i nie

np caly szereg bledow ma swoje detekcyjne ify
ale tez niektore nie maja (i to czyni to rozroznienie
dla mnie)

np powiedmy ze w dodawaniu 2+2 jest blad
i daje 5

malo kto sprawdza takie rzeczy, ale blad sie
moze rozpropagowac az program uderzy w sciane
np na bledzie ochrony pamieci

to jest tez ciekawe czy sa takie (albo czy
sa mozliwe) takie systemy w ktorych
prog nie moze uderzyc w sciane - tylko
np produkowac smieci i nic wiecej -
najprwniej i tak zostaloby wiele mozlowosci
wewnetrznego 'kalectwa' takiego progda
nawet gdyby nie mogl sie wywalic

smutne ale moze to te demka i wywiady nt
bulletstorma tak na mnie podzialaly



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

do góry

na przyklad jesli sie zastanowic
jakie sytuacje mogly by wystepowac
w przypadku proby zapisu albo
odczytu poza zakresem tablicy

- moze byc dozwolone (niby glupie
nie do pojecia ale jednak)
- moglby byc natychmiastowy crash (ma
swoje zalety)
- moglby byc cichy fail (faile maja swoje
zalety aczkolwiek tutaj raczej nie bardzo adekwatne)
- mozna tez zrobic by bylo to niemozliwe np
dajac zawinieta arytmetyke indeksu takiej tablicy)

moze sa jeszcze inne opcje - w kazdym razie jest
to ciekawe

--
sonic youth - rather ripped



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

do góry

> jak chwile sie nad tym zastanowilem (mimo
> zlego samopoczucia) to wyszlo mi ze bledy
> mozna podzielic na uchwytne (uchwycone)
> i nie
>

"Bledy" "uchwycone" nie sa bledami.
Proponuje ci sprobowac jednak zastanowic sie przede wszystkim nad precyzja
jezyka, ktorego uzywasz.

> np caly szereg bledow ma swoje detekcyjne ify
> ale tez niektore nie maja (i to czyni to rozroznienie
> dla mnie)
>
> np powiedmy ze w dodawaniu 2+2 jest blad
> i daje 5
>
> malo kto sprawdza takie rzeczy,

A niby jak to sprawdzic?
Jezeli programista z gory zna wynik, to po co pisze program (lub fragment
programu) obliczajacy tenze wynik?

> ale blad sie
> moze rozpropagowac az program uderzy w sciane
> np na bledzie ochrony pamieci
>
> to jest tez ciekawe czy sa takie (albo czy
> sa mozliwe) takie systemy w ktorych
> prog nie moze uderzyc w sciane - tylko
> np produkowac smieci i nic wiecej -

A po co komu taki program?

--
Michal

do góry

> malo kto sprawdza takie rzeczy, ale blad sie
> moze rozpropagowac az program uderzy w sciane
> np na bledzie ochrony pamieci
>
> to jest tez ciekawe czy sa takie (albo czy
> sa mozliwe) takie systemy w ktorych
> prog nie moze uderzyc w sciane - tylko
> np produkowac smieci i nic wiecej -

Moim zdaniem program nigdy nie powinien produkować śmieci. Częstą
przyczyną trudno wykrywalnych błędów jest automatyczne "zerowanie"
zmiennych na etapie kompilacji. To kardynalny błąd! Pamięć
przydzielana zmiennym powinna raczej być ustawiana na wartości
nieakceptowalne dla typu zmiennych, a przynajmniej wszystkie bity na
True, tak aby użycie wartości zmiennej, której nie nadał program,
automatycznie powodowało "uderzenie o ścianę". Zero jest najczęściej
akceptowane jako "dobra" dana, natomiast wartości skrajnie wielkie
będą na ogół prowadzić do przesterowań. Ja, w swojej praktyce stosuję
właśnie takie przekorne podejście i inicjuję zmienne tak, aby nie
wchodziło w rachubę użycie przypadkowej wartości.
apl

do góry

W dniu 2011-05-04 10:48, apl pisze:
>
>> malo kto sprawdza takie rzeczy, ale blad sie
>> moze rozpropagowac az program uderzy w sciane
>> np na bledzie ochrony pamieci
>>
>> to jest tez ciekawe czy sa takie (albo czy
>> sa mozliwe) takie systemy w ktorych
>> prog nie moze uderzyc w sciane - tylko
>> np produkowac smieci i nic wiecej -
>
> Moim zdaniem program nigdy nie powinien produkować śmieci. Częstą
> przyczyną trudno wykrywalnych błędów jest automatyczne "zerowanie"
> zmiennych na etapie kompilacji. To kardynalny błąd! Pamięć
> przydzielana zmiennym powinna raczej być ustawiana na wartości
> nieakceptowalne dla typu zmiennych, a przynajmniej wszystkie bity na
> True, tak aby użycie wartości zmiennej, której nie nadał program,
> automatycznie powodowało "uderzenie o ścianę". Zero jest najczęściej
> akceptowane jako "dobra" dana, natomiast wartości skrajnie wielkie
> będą na ogół prowadzić do przesterowań. Ja, w swojej praktyce stosuję
> właśnie takie przekorne podejście i inicjuję zmienne tak, aby nie
> wchodziło w rachubę użycie przypadkowej wartości.

VC w konfiguracji Debug domyślnie ustawia wartości bajtów 0xCC.

Część coding standards zabrania deklarowania zmiennej bez jej
inicjowania. Są też narzędzia do statycznej analizy kodu, które
pokazują potencjalne użycie niezainicjowanych zmiennych.

--
Paweł Kierski
n...@p...net

do góry

> > malo kto sprawdza takie rzeczy,
>
> A niby jak to sprawdzic?
> Jezeli programista z gory zna wynik, to po co pisze program (lub fragment
> programu) obliczajacy tenze wynik?
>

to bylo napisane troche zartem ale pokazuje
ze nie wszystkie bledy moga byc uchwycane

malo kto spodziewa sie ze procesor ma takie
bledy by dawac asserta na 4==2+2
> > ale blad sie
> > moze rozpropagowac az program uderzy w sciane
> > np na bledzie ochrony pamieci
> >
> > to jest tez ciekawe czy sa takie (albo czy
> > sa mozliwe) takie systemy w ktorych
> > prog nie moze uderzyc w sciane - tylko
> > np produkowac smieci i nic wiecej -
>
> A po co komu taki program?
wlasnie mysle ze jest mozliwe ze program ktoremu
odjac mozliwosc wpadania na sciane w
analogicznej sytuacji przyklei sie do sciany
albo wpadnie w jakies oscylacje slowem
sytuacja sie pewnie tylko zmieni - ciekawe
jest jednak o tym pomyslec


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

do góry

apl <a...@i...pl> napisał(a):

>
> > malo kto sprawdza takie rzeczy, ale blad sie
> > moze rozpropagowac az program uderzy w sciane
> > np na bledzie ochrony pamieci
> >
> > to jest tez ciekawe czy sa takie (albo czy
> > sa mozliwe) takie systemy w ktorych
> > prog nie moze uderzyc w sciane - tylko
> > np produkowac smieci i nic wiecej -
>
> Moim zdaniem program nigdy nie powinien produkowa=E6 =B6mieci. Cz=EAst=B1
> przyczyn=B1 trudno wykrywalnych b=B3=EAd=F3w jest automatyczne "zerowanie"
> zmiennych na etapie kompilacji. To kardynalny b=B3=B1d! Pami=EA=E6
> przydzielana zmiennym powinna raczej by=E6 ustawiana na warto=B6ci
> nieakceptowalne dla typu zmiennych, a przynajmniej wszystkie bity na
> True, tak aby u=BFycie warto=B6ci zmiennej, kt=F3rej nie nada=B3 program,
> automatycznie powodowa=B3o "uderzenie o =B6cian=EA". Zero jest najcz=EA=B6c=
> iej
> akceptowane jako "dobra" dana, natomiast warto=B6ci skrajnie wielkie
> b=EAd=B1 na og=F3=B3 prowadzi=E6 do przesterowa=F1. Ja, w swojej praktyce s=
> tosuj=EA
> w=B3a=B6nie takie przekorne podej=B6cie i inicjuj=EA zmienne tak, aby nie
> wchodzi=B3o w rachub=EA u=BFycie przypadkowej warto=B6ci.
> apl

ogolnie koncepcja takiego podejscia do bledow aby program jak najszybciej
walil w sciane jest w pewnym sensie chyba madra - ale to podejscie by
inicjowac takimi wartosciami mi sie nie podoba, np. po cholere inicjowac
zlymi by chwile pozniej przeinicjowywac dobrymi,[[ zreszta kwestia
przeoczonych inicjacji to raczej maly podzbior przypadkow - mz czesciej
program wypada z drogi np na skutek blednych kolejnosci
rozwiazywania operacji w wyrazeniu, ostatnio mialem jakis podobny do
takiego blad korego szukalem przez poltorej godziny ze zdziwniem
doszukujac sie o co chodzi " bitsBuffer[y][x][i] = baseAddress[yt + x<<2 +
i];" a i kiedys wczesniej zdarzalo mi sie ze bez masy nawiasow w wyrazeniach
np rzutowania nie dzialaja w domyslny sposob -- tutaj zreszta o ile
pamietam uderzal wlasnie w sciane (BAD_ACCESS)



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

do góry

Dnia Wed, 04 May 2011 10:07:13 +0200, Michal Kleczek napisał(a):
> "Bledy" "uchwycone" nie sa bledami.

Wiem, że trochę wyrwane z kontekstu - ale IHHO, to nieprawda.
Błąd to nadal błąd, póki go nie rozwiążesz.

Spotkałem się z klasyfikacją "błąd" i "defekt", gdzie błąd to ogólnie
niepoprawne działanie/implementacja, a defekt to błąd, który nie
został na czas naprawiony. Jednakże:

http://www.sjp.pl/co/b%B3%B1d
znaczenie:
1. niezgodność z obowiązującymi normami; pomyłka,
2. złe, niewłaściwe postępowanie

Błąd można usunąć; od tego jednak nie przestaje być sobą ;-)

Pozdrawiam,
Waldek

P.S. Naprawdę musicie dyskutować z trollem?

do góry

> -----------------------
> ogolnie koncepcja takiego podejscia do bledow aby program jak najszybciej
> walil w sciane jest w pewnym sensie chyba madra - ale to podejscie by
> inicjowac takimi wartosciami mi sie nie podoba, np. po cholere inicjowac
> zlymi by chwile pozniej przeinicjowywac dobrymi,[[ zreszta kwestia
> przeoczonych inicjacji to raczej maly podzbior przypadkow - mz czesciej
>-------------------
Np. robisz obliczeniówkę w wyniku której dostajesz dużą strukturę,
zmieniasz parametry i powtarzasz sesję, w wyniku której ta sama
struktura jest modyfikowana. Jeśli nie zainicjujesz ponownie, to
możesz otrzymać część wyników z poprzedniej sesji (dobrze
wyglądających), natomiast ponowne zainicjowanie skrajnie wielkimi
wartościami pokaże ci, że pewne wyniki są śmieciami. W dużym
programie, do którego wraca się niekiedy po wielu miesiącach i
modyfikuje dla aktualnych potrzeb, można łatwo przeoczyć różne
ograniczenia wykluczające wyprowadzanie takich śmieci.
apl

do góry