問題タブ [misra]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
12705 参照

standards - 「デッドコード」と「到達不能コード」の違いは何ですか?

これらの用語は同義語だと思っていましたが、デッド コードに関する MISRA のメモは、これが間違っていることを示していますか? 違いは何ですか?一方は他方のサブセットですか?

0 投票する
2 に答える
556 参照

c++ - スイッチ ケース ラベルの PC 糸くず: MISRA C++ 2008 Required Rule 5-0-12 に違反

//いくつかの static const 変数が定義されています

//スイッチケース

// この "Note 1960: Violates MISRA C++ 2008 Required Rule 5-0-12, Disallowed use of non-numeric value in a case label" に対する PC-lint の苦情

問題は、なぜ PC-lint が static const メンバーを数値と見なさないのかということです。

キャスト ケース ラベルを明示的に入力することをお勧めします (これで解決するはずです)。

ケースのラベルを型キャストする必要があるのはどの型ですか? やるだけuint8_t

このリントの問題を免除する他の方法はありますか?

0 投票する
1 に答える
394 参照

misra - QA-C は、あるプロジェクトでは複数の return ステートメントに対して警告を発しませんが、他のプロジェクトでは警告を発しますか?

私の職場では、新しいプロジェクトを開始したばかりで、このプロジェクトにも MISRA-C チェックが必要です。そして、これらを実行するために QA-C を使用しています。

私たちの最初のプロジェクトは、m2cm メッセージ パーソナリティを使用しており、何も変更されていません。

オンになっているメッセージの 1 つは、関数ごとに複数の return ステートメントがないことです。

新しいプロジェクトを開始しました。コンパイラ/チップは異なりますが、m2cm メッセージのパーソナリティは同じで、何らかの理由で、この警告が新しいプロジェクトで表示されなくなりました。.p_s同じファイルを使用して、まだ他のプロジェクトにあります。

これは、なぜこれが起こっているのかについて私たちを驚かせましたか?

メッセージ 2889 が抑制されているという抑制の兆候はどこにもありません。

0 投票する
2 に答える
1497 参照

c++ - ポインター型 'gpointer' のオブジェクトが関連のない型 'string*' にキャストされました

私はいくつかのコード MISRA の苦情を申し立てようとしていますが、次のコードがあります。

ここで、DBusCallback は call_DBus のコールバックです。

//最後の pram は、コールバックからの user_data です

コンパイルして正常に実行されますが、gpointer からの文字列変換で次の MISRA 警告が表示されます: MISRA.CAST.PTR.UNRELATED : Object of pointer type 'gpointer' cast to unrelated type 'string*'

ルールは次のとおりです。 MISRA-C++ ルール 5-2-7 (必須): ポインター型を持つオブジェクトは、直接的または間接的に無関係なポインター型に変換してはなりません。【不明 5.2.10(7)】 根拠 ポインタから無関係な型への変換結果は未規定である。

この警告を回避するためのアイデアはありますか?

0 投票する
1 に答える
807 参照

c++ - c++ ダイグラフは使用しないでください (MISRA C++ 2-5-1)

によると、MISRA C++ 2-5-1通常、有向グラフを台無しにすることは避けるべきです。ただし、一般的な演算子、、 ...を定義するために、読み取り可能な単語 、 などのand使用も避ける必要がある理由がわかりません。ornot&&||

この問題は、Sonar/MISRA の「主要な」問題として強調されています。

特定の理由で、ルールに人間が読める??=ダイグラフ (不可解な,とはまったく異なる)も含まれているのか、それともルールが一般的すぎるのか? それらを使用する際の特定のリスクや副作用は見つかりませんでしたが、間違っていますか???/

まとめ

この MISRA ルールに、人間が読めるダイグラフも含める機能上の理由はありますか? コードコンプライアンスルールをやみくもに満たすためだけにそれらを避けるべきですか、それとも背後に隠れている本当のトリッキーな理由がありますか?