Czy system MISRA-C ma zastosowanie do aplikacji systemu Linux?

Question

Rozumiem, że standardy MISRA-C są przeznaczone do oprogramowania wbudowanego : firmware. Kiedy wbudowany system Linux jest Twoją platformą produktową, czy/jakie aplikacje powinny być opracowane zgodnie z wymogami MISRA-C? Czy ktoś kiedykolwiek rozważał takie ćwiczenie?

W ogólnym sensie należy najpierw zrozumieć wszystkie "reguły", a następnie zastosować je w fazie projektowania/kodowania. Mogą istnieć takie przypadki, jak wywołania systemowe (pthread_create) i void *, które muszą zostać zmuszone do zgodności - tworząc brzydko wyglądający kod.

Answer 1

Chociaż system MISRA-C został pierwotnie stworzony jako standard tylko w zastosowaniach związanych z motoryzacją i bezpieczeństwem, nie jest to już prawdą. W dzisiejszych czasach MISRA-C jest bardziej ogólnym standardem, który można stosować w dowolnych programach C, w których błędy, awarie i problemy z przenośnością nie są pożądane.

Musisz zadać sobie pytanie, dlaczego używasz MISRA-C. Czy to dlatego, że chcesz używać go jako standardu kodowania, aby pozbyć się błędów, lub ponieważ aplikacja ma charakter krytyczny dla misji?

W przypadku systemu Linux głównym problemem będzie posiadanie własnego kodu zgodnego z systemem MISRA lub żądanie, aby było tak również w przypadku wszystkich dołączonych bibliotek. I nie ma po prostu sposobu, żebyś zrobił jądro Linux + biblioteki zgodne z MISRA, musiałbyś przepisać Linuksa od zera.

Dzięki temu Linux nie nadaje się do oprogramowania o znaczeniu krytycznym. Ale jeśli twój program nie ma charakteru krytycznego dla misji, powinieneś być w stanie używać Linuksa. Być może będziesz musiał napisać z wyprzedzeniem kilka stałych odstępstw od MISRA-C, ponieważ rzeczy, które możesz powiedzieć, spowodują problemy.

Answer 2

Jednym słowem: Nie

MISRA ma dostarczyć kilka dobrych wskazówek, ale możesz być lepiej po prostu cherry picking zasady, do których chcesz stosować (zakładając, że masz zautomatyzowane sprawdzanie w Build/analizy statycznej).

Przeglądanie plików MISRA-2004, oto kilka problemów.

Posiadanie wszystkich bibliotek zgodnych z MISRA jest samo w sobie regułą MISRA.

Zasady goto, continue i break, zwrotów funkcji, a wskaźnik arytmetyki są łamane w dosłownie miliardy wierszy zarówno jądra i kodu w przestrzeni użytkownika, więc powodzenia coraz bibliotek (lub jądra) pod zgodności.

Reguły dotyczące rzutowania wskaźnika nie będą możliwe, jeśli używasz gniazd, między innymi typowymi interfejsami API.

MISRA-2004 11.2 Konwersje nie przeprowadza się między wskaźnikiem do obiektu oraz wszelkie typ inny niż integralna typu, inny wskaźnik do obiektu typu lub wskaźnik do unieważnienia.

2004-20.x sekcje zakazu <errno.h>, <stdio.h>, <time.h> i <signal.h>. Zakaz sygnałów i sprawdzanie błędów promuje programowanie typu BAD Linux, jeśli piszesz długotrwałe, niezawodne usługi.

A żadna dynamiczna alokacja pamięci nie jest gdzieś tam.

wiem MISRA ma reguł, które pozwalają łamać zasady, jeśli ich udokumentowania (jest to prawdą dla wymaganej czy tylko doradczym ???), ale można udokumentować taaaak wiele wyjątków, że jest to naprawdę rodzaj bezcelowy.

Wszystko, co powiedziałeś, jeśli masz klienta nalegającego na zgodność z MISRA (który jest jedynym powodem, dla którego kiedykolwiek widziałem), prawdopodobnie mógłbyś udokumentować wszystkie naruszenia przepisów i wykonać jakąś ręcznie falującą próbę nazywania się Zgodny z MISRA. Więc może istnieć uzasadnienie dla udawania, że ​​jest zgodna z MISRA na Linuksie, ale nie widzę w tym żadnej korzyści technicznej.

Obawiam się, jeśli chcesz być naprawdęzgodny i potrzebują wagi ciężkiej/pełni funkcjonalny system operacyjny jesteś lepiej rozwidlone ciasto na QNX, GHS uczciwość, VxWorks itp