Czy da się zasymulować w Google zawijanie linii do usenotwego 70
char perline? Ja tak tylko pytam.

Dnia Fri, 28 Sep 2012 13:39:39 -0700, Maciej Sobczak napisal:

> 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.

Heh. Haskell?

>> > 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?

Mi mówi, i polega na czym innym. Na nie wykonywaniu potencjalnie
kosztownych operacji w wątkach realtime, tylko w wątkach nie-realtime.

> 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.

Przewidywanie czasy wykonania nie jest magią. Przynajmniej od 1 roku
studiów.

>> 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?

To zależy od implementacji, ale często w C. Minimalny kod.

> 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.

Mało wiesz o statycznej analizie. I o projektach typu Arianne. Po
pierwsze, stosuje się rozwiązania typu "mamy 3 implementacje i porównujemy
wyniki" - jeżeli dwa dają te same wyniki, engage. Po drugie, istnieje
coś takiego jak abstrakcja (w kontekście OS na przykład). Problem polega
nie na braku narzędzi, ale na stopniu skomplikowania powiązań, gdzie
niskopoziomowe IO ma jasną i prostą abstrakcję a problemy leżą w
granicach statycznej analizy. Matematycznych, nie "czy możemy coś
sparsować" - to byłby kiepski żart.

>> 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.

Chyba nigdy nie pracowałeś w zorganizowanym projekcie o dużych wymaganiach
niezawodności. Prosto jak to tylko możliwe: powyższe daje się zapewnić
mając jednego świadomego reviewera na 20 wytresowanych małp tudzież
specjalistów od innych rzeczy niż programowanie. Czyli jest trywialne.

>> 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.

J.w.

>> 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.

Systemy realtime są proste w obsłudze. To wszystko, co musi wiedzieć
programista _używający_ RTOS, w przeciwieństwie do implementatora
RTOS.

>> 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.

Ok. Smoke and mirrors i bezpieczniki Ady.

>> > 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.

J.w., automatyka na poziomie przemysłowym jest dobrze przećwiczona.

>> 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.

Wcale ale to wcale nie. Język to narzędzie, nikt nie każe młotkiem
bić się w palec. Problemy są na innym zupełnie poziomie.

>> > 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.

Nie rozumiem ironii, ale nikt nie odrzuca Ady. Problem jest zupełnie
gdzie indziej: Ada nic więcej nie daje. Porównywanie samego języka
z innym nie ma podstaw w temacie systemów tego typu. Realia są
po pierwsze dużo bardziej skomplikowane, a po drugie ci goście nie
są "aż tak głupi" jak zakładasz.

--
Edek