W dniu piątek, 28 września 2012 19:35:26 UTC+2 użytkownik Sebastian Biały napisał:

> > Zastanów się najpierw *po co* istnieją bezpieczne języki.
>
> Po to aby przeciwdziałać błedom programisty badź specyfikacji w jak
> nalepszym stopniu.

No właśnie. Ze znanych mi języków Ada robi to lepiej, niż inni.

> > czyli do interakcji ze sterowanikami urządzeń albo wręcz do bezpośrednich odwołań
do pamięci
>
>
> *G* prawda. Sterowanie rakietą poprzez algorytmy nawigacyjne *NIE*
> polega na dziobaniu po gołej pamięci bądź zapalaniu bitów na porcie IO
> uC albo sprawdzanie czy w milionie miejsc nastapil overflow.

Te rzeczy są konieczne.

> Sterowanie
> rakietą polega na realizacji (zapewne) statycznego pamieciowo zadania
> matematycznego.

Tak by było, gdyby rakiety latały tylko na papierze. Tymczasem one latają w świecie
rzeczywistym i oprócz rozwiązywania zadań matematycznych muszą wziąć na klatę różne
upierdliwości tego rzeczywistego świata, takie jak np. upływ czasu. Czy hasło "system
czasu rzeczywistego" coś Ci mówi?

Pisałem wcześniej o interakcjach z procesami fizycznymi i cały czas przy tym
jesteśmy. Upływ czasu jest procesem fizycznym, z którym interakcje polegają nie na
tym, że się grzebie po portach I/O, ale na tym, że program ma być w określonych
punktach *na czas*. To dosyć niskopoziomowy problem. Z tego co rozumiem nt. Ariane 5,
to właśnie takie niskopoziomowe rozważania doprowadziły do decyzji o wyłączeniu
bezpiecznika. Gdyby tego nie można było zrobić, to (tak tylko przypuszczam, ale nie
mam podstaw zakładać, że rozważania wydajnościowe wyciągnęli sobie z czapki) program
nie spełniłby zadanych ograniczeń. Czyli nie byłoby go.

> A jakiś drugorzędny duperelek zajmuje się częscią
> łaczącą wyniki z elektroniką.

Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?

Do rozważenia są dwie alternatywy:

1. Piszemy w bezpiecznym języku i łączymy go z modułami (tzw. duperelkami) napisanymi
w niebezpiecznym języku, np. w C albo w asm.

2. Piszemy wszystko w bezpiecznym języku i lokalnie wyłączamy bezpieczniki na
potrzeby niskopoziomowych interakcji (uwaga: upływ czasu też tu się wlicza).


Jaką niby wartość dodaną w dziedzinie bezpieczeństwa ma pierwsze rozwiązanie? Bo nie
widzę.

Natomiast w drugim przypadku widzę wartość dodaną w postaci jednolitości rozwiązania,
co ułatwia znalezienie i zastosowanie chociażby narzędzi do analizy statycznej. Znam
narzędzia, które radzą sobie z jednorodnym kodem, natomiast nie znam takich, które
sensownie analizują zlepek modułów napisanych w kilku językach. Dostępność narzędzi
to kolejny punkt na drodze do większego bezpieczeństwa i ten drugi wariant daje tu
większe możliwości. Ada jest bezpieczniejsza właśnie przez to, że to, co chciałbyś
zrobić w C, możesz dalej robić w Adzie.

> Prawdopodobnie dałbym osobiście radę naklepać bezpieczną klasę do
> konwersji w C++ która dzięki prostym zabiegom *uniemożliwiła* by
> programiście jej nie-użycie bez chamskich sztuczek.

Jeśli ta niemożność uniemożliwiłaby spełnienie oczekiwań związanych z koniecznością
interakcji z procesami fizycznymi, to Twoja klasa nie nadawałaby się do robienia
bezpiecznych systemów. Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do
dyzpozycji są wskaźniki i reinterpret_cast (oraz memcpy, itd.). Zapewniam Cię, że ten
sam programista, który wyłączył bezpieczniki w Adzie, poradziłby sobie z Twoją
niehakowalną klasą. W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.

> Głupi C++ potrafił
> by lepiej zabezpieczyć

Nie, nie potrafiłby. Użycie systemu typów jako mechanizm ochronny miałby podobną
skuteczność i podobnie nie zatrzymałby zdeterminowanego programisty.

> przed radosną twórczością byłych programistów
> demek.

Jak już pisałem, nie znam nikogo z tego zespołu, więc nie wypowiadam się nt.
przeszłości zawodowej tych ludzi.

> Żałosne.

Na razie pokazałeś tylko, że nigdy nie widziałeś systemu sterowania. W szczególności
systemu sterowania czasu rzeczywistego.

> Tutaj *nie* było niskiego poziomu. Jesli zaś ktoś matematykę i overflow
> implementuje ręcznie na bitach jak w przytoczonym przykładzie to jest
> idiotą.

Ten program był poprawny, bo był przeznaczony dla poprzedniego modelu rakiety i tam
wpisywał się w zadane warunki techniczne. Nie widzę powodu, dla którego można by tego
programistę nazwać idiotą - napisał program w zgodzie z danymi. Natomiast to, że ten
moduł bezrefleksyjnie użyto w nowszej rakiecie, w której warunki techniczne były już
inne, to błąd wdrożeniowy. Ktoś wykorzystał słabsze cegły do budowy większego budynku
- to nie wykonawca cegieł jest tu idiotą, tylko ten koleś, który wybrał złe cegły.
Język pomógłby, gdyby miał włączony bezpiecznik.

> > Otóż żeby dany język w ogóle się do tego nadawał
> >, to musi udostępnić wszystkie narzędzia z rodziny
> > memset, memcpy, reinterpret_cast oraz link z dowolnym symbolem.
>
> Żadna z tych funkcji nie jest wymagana w liczeniu kąta otwarcia
> przepustnicy lewej dyszy.

Co najmniej jedna z nich jest wymagana, żeby ta dysza faktycznie sie otworzyła. Bez
tych ficzerów rakieta poleci tylko na papierze.

> Te narzędzia na szczęscie udostepnia asm.

Rozumiem - czyli bezpieczne rozwiązanie to połączenie bezpiecznego języka z asm, tak?

Pomińmy fakt, że już samo łączenie języków to jazda bez pasów dokładnie równoważna
reinterpret_cast, bo ze względu na rozdzielność systemu typów właśnie to trzeba
zrobić na granicy języków.

Po prostu zaplątałeś się we własne gacie w tej dyskusji.

> > Proste?
>
> Jednak za bardzo to uprościłeś. Uprościłeś do systemów embedded
> zajmujących się *bezpośrednim* sterowaniem. To tylko pewien zbiór
> problemów. Niekompletny.

Tak. Ale wystarczy do wykazania, że nie masz racji odrzucając Adę w całości. Twoje
stwierdzenie, że Ada jest do niczego, było ogólne - mi wystarczy wskazać jeden
przykład, żeby Twój ogólny kwantyfikator wyłożyć.
Tym przykładem są... bezpieczne systemy. Ot, ironia.

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