MISRA-C是否適用於Linux應用程序

我知道MISRA-C標準適用於嵌入式固件。當嵌入式Linux是您的產品平臺時，您的嵌入式應用程序可以/應該被開發爲符合MISRA-C標準？有沒有人考慮過這樣的練習？MISRA-C是否適用於Linux應用程序

我的一般意義是，您必須首先了解所有「規則」，然後將它們應用於設計/編碼階段。可能會有像系統調用（pthread_create）和void *這樣的實例需要強制遵從 - 產生難看的代碼。

來源

2015-04-29 Andrew W.

按文件標題MISRA-C適用於所有*關鍵系統*，並可用於超出此範圍的任何應用程序。如果使用非嵌入式代碼，您對某些規則（特別是建議）的處理方式可能會更加寬鬆。 – Andrew

儘管MISRA-C最初是作爲汽車和安全關鍵應用的標準創建的，但這不再是事實。如今，MISRA-C更多地是一個通用標準，可用於任何不需要錯誤，崩潰和可移植性問題的C程序。

您需要問自己爲什麼使用MISRA-C。是否因爲您希望將其用作編碼標準來擺脫錯誤，或者因爲應用程序具有關鍵任務性質？

對於Linux的情況，主要問題是如果你只有自己的代碼MISRA兼容，或者如果你會要求這也適用於所有庫。而且你沒有辦法讓Linux內核+庫MISRA兼容，你必須從頭重寫Linux。

這使得Linux不適合任務關鍵型軟件。但是如果你的程序不具有任務關鍵性質，你應該可以使用Linux。您可能需要事先寫好一些MISRA-C的常規偏差，因爲您可以看出這些偏差會導致問題。

來源

2015-04-30 13:18:25 Lundin

一句話：號

MISRA確實提供了一些很好的指導方針，但你會更好只是採摘櫻桃到要堅持（假設你已經自動在構建/靜態分析檢查哪些規則）。

通過MISRA-2004東西瀏覽，這裏有一些問題領域。

使您的所有庫符合MISRA標準本身就是MISRA規則。在goto，continue和break，函數返回，和指針運算

規則違反了數十億內核和用戶空間代碼的行，運氣這麼好下履約讓你的庫（或內核）。

如果使用套接字以及其他常用API，則無法遵循指針投射規則。

MISRA-2004 11.2換算不得指針之間執行到對象和比一體型以外的任何類型，另一個指針到對象類型或指向void。

2004-20.x部分禁止<errno.h>，<stdio.h>，<time.h>和<signal.h>。如果你正在編寫長期運行的強大的服務，那麼禁止信號和錯誤檢查會促進BAD Linux編程。

並沒有動態內存分配是在那裏的規則。

我知道MISRA有規矩，讓你，如果你記錄這些違反規則（這是真的爲需要或只是諮詢 ???），但你會記錄SOOOO很多例外，它是那種真的無意義。如果你有一個客戶堅持遵守MISRA（這是我見過它使用的唯一原因），你或許可以記錄你所有的規則違規行爲，並做出一些手工波浪式的嘗試來稱呼你自己符合MISRA。因此，假設在Linux上僞裝成符合MISRA標準的商業案例可能會有一些商業案例，但我認爲它幾乎沒有技術優勢。

我怕，如果你想成爲真正符合，需要一個重量級/全功能的操作系統，你最好分叉爲QNX，GHS完整性，VxWorks的麪糰，等

來源

2015-04-30 17:48:19

圖書館是否必須符合MISRA是一種爭論。因爲你會發現無處不在的書面庫，而不僅僅是Linux源代碼。這就是爲什麼我認爲如果OP只希望MISRA-C提高自己的代碼，忽略這些庫是很好的。一般來說，Linux程序員可以從採用MISRA或MISRA的子集中受益，以便他們可以瞭解真實的編碼標準。與其認爲即使在內核項目之外，愛好者級別的「Linux內核風格指南」也是某種優秀編程實踐的佳作。 – Lundin

然而，您通常必須使用MISRA-C的原因不是因爲「客戶」，而是因爲您必須符合安全關鍵應用的行業安全標準。 IEC 61508（工業/通用），ISO 26262（汽車），DO-178（航空電子設備）等。這些標準要求您使用更安全的語言子集，並使用靜態代碼分析，使您幾乎可以選擇MISRA-C和SPARK Ada。但是鑑於至少61508和26262以及所有其他SIL標準大都充滿了無稽之談，我想最終可能歸結爲「客戶堅持」:) – Lundin

大多數MISRA要求都是基於開發軟件的確定性儘可能在所有操作條件下進行。由於CAN，ARINC-428和MIL-STD-1553（通常）同步（與IP的固有異步）相比，你不使用'malloc'。確定性。保證確定性性能是硬實時系統（尤其是任務或安全關鍵性系統）中最爲關心的問題，但對系統總體性能常常是*有害的，因此不屬於通用操作系統。 –

MISRA-C是否適用於Linux應用程序

回答

相關問題