mk <reverse_lp.pw@myzskm> wrote:

> Mam nadzieję, że nikt nie wierzy w to, że dzięki tworzeniu kodu zgodnego
> z MISRĄ dostajemy bezbłędne i bezpieczne oprogramowanie.

To na pewno nie - warningi to tylko narzędzie pomocnicze.

> http://supp.iar.com/FilesPublic/UPDINFO/004916/arm/d
oc/EW_MisraC2004Reference.ENU.pdf
> (patrz rozdział "MIRSA C:2004 rules reference")

Przyjrzałem się i większość ma sens, ale części nie rozumiem. Jest gdzieś
dostępne wyjaśnienie, czemu niektóre reguły mają służyć? Są sposoby na
świadome obejście tych warningów, np. jak /* FALLTHROUGH */ rozpoznawane
przez linta?

Ciekawe jak zgodnie z misrą loguje się różne wartości, skoro ellipsis jest
niedozwolony. Swoją drogą ja bym raczej nakazał używanie odpowiedniego
__attribute__ lub podobnego rozszerzenia kompilatora, żeby warningować
niezgodność przekazywanych typów z format stringiem.

Rzuciła mi się w oczy też zasada 19.10. Jest napisane, że:

#define MY_MACRO_1(x) (x) + 2

to prawidłowy kod. Wg mnie powinno być:

#define MY_MACRO_1(x) ((x) + 2)

Czemu? 10 * makro != makro * 10, a to wszystko != temu, co autor miał na
myśli. Postawili nacisk na wrzucenie argumentów makra w nawiasy, ale nic
nie napisali o wrzuceniu w nawiasy całego makra (zawierającego operatory)
- ciekawe dlaczego.

Rozdział 20 też mocno kontrowersyjny. Brak malloc, errno, stdio.h, time.h...
Właściwie nic nie ma. Ciekawe jak to uzasadniają.

>> A z drugiej strony przeraża mnie komplikowanie prostych systemów. Rzeczy
>> takie jak np. hamulce, czy sterowanie przepustnicą, powinny być proste,
>> mechaniczne, niezależne od elektroniki ani jakiegokolwiek softu,
>
> No i dochodzimy do istoty sprawy. Przy takim postawieniu spraw
> natychmiast nasuwa się pytanie: czy to będzie w ogólnym rozrachunku
> bezpieczniejsze? Bez ABS, ASR? Skąd taka dysproporcja zaufania do
> mechaniki i elektroniki?

Po przemyśleniu może inaczej - zaufanie nie do mechaniki, tylko do prostoty.
Elektronika elektronice nierówna. Weźmy generator na 555 i na procesorze.
Pierwszy jest dużo mniej wrażliwy na zakłócenia.

Trudno mi teraz wymyśleć jakiś przykład, ale ogólnie chodzi mi o to, że
nieprawidłowa praca skomplikowanego mechanizmu/oprogramowania powinna być
wyłapywana przez jakiś zewnętrzny, w pełni automatyczny (czy elektroniczny,
czy mechaniczny) mechanizm, sprawdzający np. zakres zmian sterowanego
czynnika. Najprostszym przykładem jest watchdog.

Co do różnicy mechanika vs elektronika - oba mogą zawieść. Mechanika może
się zatrzeć, urwać, zniszczyć po udarze mechanicznym, elektronika może
być zakłócona (lub też uszkodzona mechanicznie). Ogólnie chodzi o takie
projektowanie, żeby awarię tej mechaniki (lub elektroniki) dało się wyłapać
i obejść.

Przykład - linka powrotu gazu w motocyklu. Nie jest potrzebna, bo wystarczy
jedna linka i sprężyna przy przepustnicy, ale w motocyklach montuje się drugą
linkę, która działa w drugą stronę - jak się pierwsza zablokuje, to druga
może zamknąć przepustnicę.

Co do systemów antypoślizgowych - nie znam dobrze szczegółów konstrukcyjnych,
ale taki system jest ok, dopóki jest zaimplementowany jako dodatek. Jego
awaria nie powinna powodować utraty hamowania.

> Poduszkę powietrzną też należy odpalać czysto mechanicznie? Potrafi zabić...

Poduszka to skomplikowany temat - i wycofałem się z czysto mechanicznych
rozwiązań :) Myślę że jest dobrze zrobiona - prosty układ elektroniczny,
wypuszczenie azotu po rozprężeniu by design, możliwość wyłączenia, jeżeli
ktoś przewozi dzieci, jest za mały, musi mieć mniej niż 10 cali do poduszki
i w innych przypadkach...

>> tego failsafe powinien być zrealizowany by design (np. hamulce w pociągu,
>> pozwalające kręcić się kołom, gdy jest ciśnienie w przewodach - gdy wagon
>> się odczepi lub przewód hamulcowy uszkodzi, to hamulce zakleszczają się
>> na kołach i wyhamowują skład).
>
> Warto zaaplikować w polityce.

Tzn?

--
Gof