On Saturday, August 31, 2019 at 10:44:23 PM UTC+2, slawek wrote:
> "M.M." <...@...c> Wrote in message:
> > Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt
zaawansowanymprogramistom tworzyć bezpieczny kod.
>
>
> Nic dziwnego.
>
> Tyle że cytowane (link) regułki to takie raczej mało poważne jest.
> No i to nie jest gdzieś tam na serwerze NASA, tylko jakiś
> blogasek kogoś o kim - szczerze - pierwsze słyszę. Autorytet z
> niego taki jak z Piotrusia z IIIc.
>
> Więc nie łykałbym tego niczym młody pelikan. Także dlatego że
> trochę takich manifestów czytałem.

Tam jest to lepiej uzasadnione, więcej tekstu, większa szansa na
prawidłowe odczytanie tego co autor miał na myśli:

http://web.eecs.umich.edu/~imarkov/10rules.pdf

Pozdrawiam.

do góry

On 2019-08-31 18:42, slawek wrote:
> Tego rodzaju zalecenia (patrz np. MISRA) można rozmaicie rozumieć.

[...]
99% "pokrycia" to 1-6 itp
1% to 7 itp

AK

do góry

On 2019-08-30 19:21, Wojciech Muła wrote:
> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
>> https://fossbytes.com/nasa-coding-programming-rules-
critical/
>
> Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-s
tuff
>
> BTW "All code must be compiled, from the first day of development, with all
compiler warnings enabled at the compiler's most pedantic setting." używamy, polecam
(-Werror jest, wbrew pozorom, wicej niż korzystne)

Eee... Co to są compile warnings? Znam tylko compile errors :(
Slowem b.dobra zasada.

AK

do góry

Mateusz Viste <m...@w...tell> wrote:

>> 2. All loops must have a fixed upper-bound. It must be trivially
>> possible for a checking tool to prove statically that a preset
>> upper-bound on the number of iterations of a loop cannot be exceeded. If
>> the loop-bound cannot be proven statically, the rule is considered
>> violated.
>>
>> Zgadzam się.
>
> Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.
>
> for (;;) {
> wait_input();
> do_job();
> }
>
> Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A
> jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)

Ok, fakt, nie myślałem o pętli głównej :) Ona często nigdy się nie kończy.
Ciekawe jak to rozwiązują, jeśli to jest sztywna zasada a nie zalecenie,
które można ominąć komentarzem: // this is main loop, rule #2 does not
apply.

>> Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to
>> samo. Widzę w tym logikę, ale nie chciałbym tak pisać :(
>
> Logika jest - ale chyba tylko w lotach kosmicznych albo innych
> przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać.

Z drugiej strony... jeśli się nie uda, to i tak powinny być inne
mechanizmy fail-safe (niekoniecznie w sofcie), które to wyłapią.

> W praktyce program graficzny będzie alokował pamięć zależnie od tego,
> jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało
> pamięci to i tak może sobie pomalować w 640x480, a przy większych
> bitmapach dostanie zonk.

No właśnie.

>> 7. The return value of non-void functions must be checked by each
>> calling function, and the validity of parameters must be checked inside
>> each function.
>>
>> Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba
>> stosować, czy zbiór sugestii.
>
> if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();

Tak, m.in. :)

> Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Pewnie nie większy niż wśród programistów w korpo...

Z drugiej strony u mnie codzienne spotykanie się z absurdami i walenie
prywatną głową w służbowy mur raczej nie skutkuje depresją. Jeśli już
to wypaleniem. Objawy nawet podobne, ale jednostka (chorobowa?) inna.

Kati Morton (yt) miała cykl na temat wypalenia.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

M.M. <m...@g...com> wrote:

> Bez kontekstu można powiedzieć, że powinien zapisać w pliku logu że doszło do
> takiej sytuacji, żeby programista szybciej zaczął się zastanawiać nad
> przyczyną problemu.

A zapis w pliku logu może mieć swoje własne błędy...

Z drugiej strony, Linuksowe funkcje openlog(3), syslog(3), closelog(3),
vsyslog(3) zwracają void.

> A tak poza tym, dużo softu ma bezpośredni wpływ na życie, zdrowie,
> pieniądze; jeszcze więcej softu ma pośredni wpływ na ważne sfery życia.
> Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający
> niezbyt zaawansowanym programistom tworzyć bezpieczny kod.

Czy niezbyt zaawansowani programiści powinni tworzyć krytyczny kod?

> Natomiast kompulsywne trzymanie się dowolnych skrótowych reguł,
> zwłaszcza bez dobrych intencji, oczywiście/zawsze źle się kończy, np.
> depresją programistów.

U mnie na zdrowie psychiczne wpływają wszelkie absurdy korpo niemające
związku z samym programowaniem. Jakby się wszyscy odp...lili i dali mi
w spokoju robić to, co umiem i za co mi płacą, to nie miałbym na co
narzekać.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

Adam Klobukowski <a...@g...com> wrote:

> Te reguły wynikają z tego że to jest praktycznie programowanie
> embeded/raw metal/realtime.

Pewnie tak, wynika z kontekstu, ale przy opisie tych reguł nie było to
napisane.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

> > https://fossbytes.com/nasa-coding-programming-rules-
critical/
>
> Ot, bajeczki dla nastolatków.

Nie, po prostu ktoś sobie na blogu napisał. Najprostszy standard kodowania MISRA-C ma
230 stron, ostatnio opublikowany z AUTOSAR dla C++ ma 370 stron. Ten blog nie porusza
nawet wierzchołka zagadnienia.

Ogólnie, to nie są jakieś dziwne reguły, właśnie takich należy się spodziewać.
Warto też pamiętać, że pomimo wysokiej popularności NASA jako pop-kulturowego brandu,
to nie NASA jest frontem walki o jakość - wynika to z faktu, że w tej branży
(podobnie jak w wojsku) nie obowiązują reguły certyfikacji czy homologacji takie jak
w cywilnych branżach. Tzn. oni oczywiście dbają o pieniądze podatnika (w sensie -
szkoda stracić drogą rakietę) i o swoją reputację (w sensie - jak ją stracą, to
kolejnego projektu mogą nie mieć), ale poza tymi dwoma wartościami nie mają o co
dbać, bo w szczególności pilot rakiety jest w oczach opinii publicznej bardziej
żołnierzem, niż obywatelem, więc jego strata jest przez publiczność postrzegana jako
godna ofiara na ołtarzu postępu. Przecież wiedział, że może zginąć, nie?

Inaczej mówiąc 1: publiczna akceptacja fakapu w tej branży jest całkiem wysoka, w
odróżnieniu od dziedzin, gdzie się zabija niewinnych obywateli.

Inaczej mówiąc 2: pomimo tego, że te kilka reguł wygląda strasznie dla "normalnego"
programisty, to typowy projekt NASA mógłby nie przejść rygoru obowiązującego w
lotnictwie cywilnym. No, serio, nie wystarczy mieć funkcje krótsze niż 60 linijek,
żeby przejść przez proces certyfikacji[*].

[*] Który to proces właśnie traci reputację przez ostatnie lotnicze fakapy. Tak,
zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

> Ciekawe jest to czego w tym nie ma:
>
> 1. Architektura i wzorce projektowe.
> 2. Statyczna analiza kodu.
> 3. Testy jednostkowe i integracyjne.
> 4. Dokumentacja.
> 5. Audyt. XP
> 6. Metodyka (waterfall ?!?)

Ale chyba nie o tym był ten blog. Natomiast warto zauważyć, że standard kodowania
jest właśnie po to, żeby zrobić punkt 2 powyżej i żeby sobie ułatwić osiągnięcie
jeszcze kilku innych celów jakościowych. I tylko po to. Gorzej, że z powodu takich
blogów ludzie potem myślą, że standard kodowania jest jedyną rzeczą, która odróżnia
proces krytyczny od "normalnego" i tylko na nim się skupiają. Tymczasem te "straszne"
reguły to jest najmniejszy problem. Klepanie kodu to tylko kilka procent wysiłku,
nawet z tymi strasznymi regułami.
Więc bez przesady.

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

do góry

On 2019-09-01 22:55, Maciej Sobczak wrote:

> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

Hehe. Smiechu warte.

AK

do góry

> > 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.
No więc dlaczego śmiechu warte?

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

do góry

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

AK

do góry