W dniu sobota, 27 października 2012 16:53:37 UTC+2 użytkownik Baranosiu napisał:

> > type My_Int is range 0 .. 1000;

> No jak tak obetniesz,

Tak obciąłem, bo nie miałem innego pomysłu. Nie podałeś, jaka to dziedzina.
Temperatura wody w stanie ciekłym w czajniku to 0..100, prędkość jakiegoś tam
samochodu to 0..250, ilość zajętych siedzeń w teatrze to 0..814, numer nuty w
muzycznych kontrolerach MIDI to 0..127, numer piętra w budynku to 1..25, itd. Czyli
każdy *realny* problem ma jakieś *realne* wartości, z których można zrobić *realną*
definicję typu w programie.
Nie mam pojęcia, z jakiej dziedziny pochodzi Twój przykład z rekurencyjnie liczoną
silnią. Prawdopodobnie pochodzi z dziedziny newsgrupowych flejmów na temat
nieistniejących problemów...

> ale daj range Integer'First+1 .. Integer'Last-1;

... czyli zgadza się.

> Po prostu
> był błąd w specyfikacji Ada95 (a taka obowiązywała w momencie lotu
> Ariane 5 :D)

W Ariane 5 nie było problemu z przekręceniem typu bazowego, tylko z rzutowaniem. I
nawet nie dotyczyło to typu Integer.

> Załóżmy, że sprzętowo Integer jest powiedzmy 8-bitowy

Ale nie jest.

> tak wiem, według specyfikacji musi być co najmniej
> 16-bitowy ze znakiem, ale chodzi o prostotę przykładu

Czyli: "olejmy specyfikację w miejscu X, wtedy uda się podkreślić niedociągnięcie w
miejscu Y".

Krótko: masz rację.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Dnia 29.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
>> Po prostu
>> był błąd w specyfikacji Ada95 (a taka obowiązywała w momencie lotu
>> Ariane 5 :D)
>
> W Ariane 5 nie było problemu z przekręceniem typu bazowego, tylko z rzutowaniem. I
nawet nie dotyczyło to typu Integer.

Ależ tam właśnie był overflow, jeden moduł (stary) pracował na
16-bitowych danych a drugi (nowy) liczył z 32-bitową dokładnością i
jak powiedzmy wyszło z obliczeń 16#20001 (przepełnienie) to do
"starego" modułu trzeba było wstawić 16#7FFF (co było w innych
miejscach zrobione na if-ach) a program wstawiał 16#20001 co stary
moduł widział jako 16#0001 (i nie miał szans wykryć, że to wynik
przepełnienia, bo programista "starego" modułu dopuścił jako parametr
wejściowy dowolną liczbę całkowitą - w momencie gdy to pisał chodziło
o dane 16-bitowe, stary moduł 16-bitowy został ponownie wykorzystany z
komputerem 32-bitowym). Dziwi mnie tylko że ktoś te dwa "if-y" opuścił
ze względu na potrzebę obniżenia obciążenia komputera mimo że we
wszystkich innych miejscach pozostały (no i nawet jeśli wyrzucono
generowanie wyjątków w czasie wykonania z tego fragmentu kodu, to
przecież na 99% kompilator w momencie kompilacji ostrzegał o
możliwości przepełnienia :D).

>> Załóżmy, że sprzętowo Integer jest powiedzmy 8-bitowy
>
> Ale nie jest.
>
>> tak wiem, według specyfikacji musi być co najmniej
>> 16-bitowy ze znakiem, ale chodzi o prostotę przykładu
>
> Czyli: "olejmy specyfikację w miejscu X, wtedy uda się podkreślić niedociągnięcie w
miejscu Y".

Ok, niech będzie dla 16-bitów (zgodnie ze specyfikacją):

type My_Type range -25600 .. 25600;

I mnożenie 2*25600 daje (w 16-bitach ze znakiem) -14336 (czyli wg
'range' dopuszczalną wartość) - zasada dokładnie ta sama.

> Krótko: masz rację.
>

Nie o to chodzi czy mam czy nie mam, nie potrafię po prostu zrozumieć
jak włączenie wyjątków w czasie wykonania mogło coś zmienić w tym
przypadku (zakładając, że kod "starego" modułu nie zostałby zmieniony)
i dlaczego to mogło uratować sprawę, ale ok, nie ciągnę dalej tematu.

do góry

W dniu poniedziałek, 29 października 2012 12:01:19 UTC+1 użytkownik Baranosiu
napisał:

> Nie o to chodzi czy mam czy nie mam, nie potrafię po prostu zrozumieć
> jak włączenie wyjątków w czasie wykonania mogło coś zmienić w tym
> przypadku

No właśnie. Gdzieś tam bliżej początku tego flejma napisałem:

"Można jeszcze się pozastanawiać co by się stało, gdyby tego handlera nie wyłączono."

Bądźmy realistami: pewnie skoczyłoby się tak samo, bo nie widzę mechanizmu, który by
a) poprawił rakietę lub b) pozwolił programowi dalej poprawnie działać z wartościami
spoza zakresu, dla którego został zaprojektowany.
Czyli tak czy inaczej rakieta skończyłaby jako kula ognia i dymu.

W tym konkretnym przypadku jest to argument na poparcie tezy, że łatwiej napisać
program, w którym wyjątków nie ma, niż taki, który wyjątki sensownie obsługuje.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry