On Monday, September 2, 2019 at 9:33:41 PM UTC+2, AK wrote:
> On 2019-09-02 14:16, Maciej Sobczak wrote:
> >>> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
> >>
> >> Hehe. Smiechu warte.
> >
> > O, fajna dyskusja będzie. Dlaczego śmiechu warte?
> >
> > Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być
jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że
trzeba być bardziej jeszcze bardziej rygorystycznym.
>
> Tak, ale w inny - normalny sposob (wyjasnien nizej).
>
> > No więc dlaczego śmiechu warte?
>
> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.
>
> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> o wymioty... :(

Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
programisty od jakiegoś czasu już nadaje się do bezpiecznego
programowania.

Pozdrawiam

do góry

> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"

Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.

> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.

Masz rację. Ale problem polega na tym, że to właśnie programiści (ogólnie: przemysł)
trzymają się tych języków. Przemysł jest zdumimewająco odporny na zmiany w tej
dziedzinie, więc jedyne, co można przemysłowi zaproponować, to dokręcanie śruby na
tym, co mają. Dlatego powstają standardy kodowania.

I bez przesady z tymi regułami, których się nie da zapamiętać. Wystarczy zrozumimeć,
skąd się wzięły, wtedy nie trzeba ich już pamiętać, bo ich stosowanie staje się
naturalne. Naprawdę, musisz pamiętać regułę o niestosowaniu goto, żeby nie stosować?
Ja nie stosowałem zanim się dowiedziałem, że jest taka reguła gdzieś w jakimś
standardzie.

Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do
rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być ileś tam
assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też pokazuje, że NASA
nie jest wcale wyznacznikiem najlepszej praktyki. Albo ten blog jest od czapy, to też
możliwe.

> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> o wymioty... :(

Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają
osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla
konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca
języka C, to Twój zysk.
Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak
samo, jak reszta.

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

do góry

On Tue, 3 Sep 2019 01:58:01 -0700 (PDT), Maciej Sobczak wrote:

> Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do
> rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być
> ileś tam assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
> Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też
> pokazuje, że NASA nie jest wcale wyznacznikiem najlepszej praktyki. Albo
> ten blog jest od czapy, to też możliwe.

Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
najmniej dwie na funkcję, czyli nie ma górnego limitu.
Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

--
pozdrawiam
Roman Tyczka

do góry

On 2019-09-03 09:42, M.M. wrote:
> Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
> programisty od jakiegoś czasu już nadaje się do bezpiecznego
> programowania.

Zwyczajnie bzdużysz/mylisz się o 180st.

AK

do góry

On 2019-09-03 10:58, Maciej Sobczak wrote:
>> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
>
> Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.

Ada nie powstala na uniwersystecie. PL/I tez nie.

AK

do góry

On 2019-09-03 10:58, Maciej Sobczak wrote:
>> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
>> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
>> o wymioty... :(
>
> Przemysł ma inne zdanie. Nie da się zakazać używania języka C.

Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
nie jest... ("wiedza" managementu brana z prezentacji i video-konferencji).
Po drugie: Otoz da sie. Bardzo prosto.
Poza tym (jak pisalem) nie jest to niezbedne.
Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
Jezyk niech sie zwie po prostu Misra-C

> I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają
osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla
konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca
języka C, to Twój zysk.
> Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak
samo, jak reszta.

Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
tym samym mlotkiem w leb potraktowac.

AK

do góry

On Tuesday, September 3, 2019 at 6:43:54 PM UTC+2, AK wrote:
> On 2019-09-03 10:58, Maciej Sobczak wrote:
> >> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> >> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> >> o wymioty... :(
> >
> > Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
>
> Po prwwsze: Przemysl nieraz dowiodl (i ciagle dowodzi), ze za madry
> nie jest... ("wiedza" managementu brana z prezentacji i video-konferencji).
> Po drugie: Otoz da sie. Bardzo prosto.
> Poza tym (jak pisalem) nie jest to niezbedne.
> Wystarczy stworzyc kompilator z zaszytymi restrykcjami Misry.
> Jezyk niech sie zwie po prostu Misra-C
>
> > I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają
osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla
konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca
języka C, to Twój zysk.
> > Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak
samo, jak reszta.
>
> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
> tym samym mlotkiem w leb potraktowac.

Dlaczego porównanie języka programowania do gumowego młotka jest
dobre?

Pozdrawiam

do góry

On 2019-09-03 20:04, M.M. wrote:
>> Nie da sie zakazac przybijania gwozdzi gumowm mlotkiem.
>> Co wiecej przy "odrobinie" wytrwalosci i fizyce (ciekly azot -> Mi-sry)
>> da sie to zrobic. Tyle tylko ze takiego "fachowca" nalezy (przynajmniej)
>> tym samym mlotkiem w leb potraktowac.
>
> Dlaczego porównanie języka programowania do gumowego młotka jest
> dobre?

Dlatego ze dosłowną wrecz implementacją "paradygmatu" gumowego mlotka
w dziedzinie okraszonej slowem "safety" jest wrecz stworzony do
problemow j.prog. C/C++.

AK

do góry

> Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> najmniej dwie na funkcję, czyli nie ma górnego limitu.
> Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu,
bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. Nawet jeśli
przyjmiemy założenie, że źle działający program należy zabić na miejscu, to nie można
obowiązku zabijania nałożyć na ten sam program, o którym właśnie mówimy, że źle
działa. To jest bez sensu. Monitor/strażnik, jeśli już, musi być niezależnym bytem.

To, że MISRA-C i AUTOSAR nawet nie wspominają o asercjach nie jest przypadkiem. A to,
że AUROSAR wspomina o static_assert też nie jest przypadkiem, bo wykrycie czegoś w
czasie kompilacji, czyli przed uruchomieniem, akurat ma sens.

Więc zalecanie, żeby funkcja miała co najmniej dwie asercje, to jakaś pomyłka.

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

do góry

> >> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> >
> > Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.
>
> Ada nie powstala na uniwersystecie. PL/I tez nie.

Chciałeś, żeby był nowy.

--
Maciej Sobczak

do góry