MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013

MISRA-C2012と ISO/IEC 9899:2011

MISRA-C-Training ver6 2013.06.20

04/13/2023 (c)[email protected], @kaizen_nagoya

1

工学博士・技術士（情報工学）名古屋市工業研究所　小川清

今頃 C言語？

04/13/2023 (c)[email protected], @kaizen_nagoya 2

• CPUが実行するのは機械語。

• 多くの CPU提供者が、 CPUとアセンブラ、 Cコンパイラを同時に出荷。

• 実行している内容でよいかどうかをたしかめるのはアセンブラ。

• min-CAMLでは直接アセンブラを生成することによって高速化を実現。

• Cを生成すれば、対応 CPUが一気に広がる。

• UNIX/Linuxなどの OSは Cで記述している。

• Cコンパイラを Cで記述している。

• アセンブラで書けることなら、 Cで書ける。

よくある意見


Q: プログラミング言語の自動生成をしていて自分でコードを書かないので関係ない。

A: 自動生成で C言語を使っているとキャストの仕方が不十分で誤差が拡大したり、０割の発生原因となります。MISRAでは、自動生成の出力規則も定義しています。

Q: 試験 (test)担当で、直接コードを書かないので関係ない。

A: MISRA-Cは、 C言語の部分集合 (subset)です。MISRA-Cに対応すると試験がしやすいコードになります。

Q: 自分は天才プログラマなので一切の規制に反対する。

A: 天才の書いたプログラムを、凡人が間違ったプログラムにしてしまうことがあります。凡人にも理解出来るコードが書けるのも天才の技の一つとお考えください。

背景 CPU販売者が言語としてアセンブラと Cを提供。

Cコンパイラも Cで記述 CPUの発展を阻害しないように、 Cプログラマに不必要な負荷をかけないように (Cの精神 :the spirit of c）、 C言語規格には「未規定」，「未定義」，「処理系定義」がある。

C言語規格には OSの存在を前提としたホスト環境（ OSあり ,mainあり）と

OSの存在を必ずしも想定していないフリースタンディング環境とがある。 OSなくてもよくMainは必要ない。

C言語規格には OSの一部かもしれないライブラリがある。 OSも Cで記述


4

Ｃ言語の規格 K&R（デファクト） C言語の作者の文書アメリカ規格（デジュール）

ANSI X. 1989(C89):1999版から ISO/IECの標準制定と同時進行

国際規格 :フリースタングィング環境 (main無可 )，ホスト環境（ main引数有）ISO/IEC 9899:1990(C90=ANSI C89)ISO/IEC 9899:1999(C99)ISO/IEC 9899:2011(C2011)

国内規格JIS X 3010:1993(C90), JIS X 3010： 2004(C99)www.jisc.go.jpで無償で閲覧可


5

JIS C解説 (Cの精神）　 © JIS1. 既存のコードを救うことが重要であり、既存の処理系を保護することは、重

要視しない。2. 可搬性のある原始プログラムが書けるようにする。 ( 高級アセンブラ的な使

い方による）可搬性がないプログラムを禁止してはならない。3.( 既存の仕様からの）暗黙の意味変更（ quiet change) は極力避ける4. 規格は処理系の作成者とプログラマとの間の約束事を記述するものである。5. 次の C の精神を遵守する .

1. プログラマを信頼する2. プログラマが必要である事項を行うことを妨げない3. 言語は小さく、コンパクトに保つ4. 一つのオペレーティングシステムには唯一の方法を割り当てる

たとえ可搬性が保障されない方法であったとしても、実行効率を上げる余地を残しておく。


6

The spirit of C, Additional Principles for C1X

ISO/IEC JTC1 SC22WG14 N125012. Trust the programmer, as a goal, is outdated in respect to

the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C1Xversion of the C Standard should take into account that programmers need the ability to check their work.

13. Unlike for C9X, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the Standard and the commercial implementation compatible.

14. Migration of an existing code base is an issue. The ability to mix and match C89, C99, and C1X based code is a feature that should be considered for each proposal.


動くプログラムで教育（応用）

C Puzzle Book トリッキーなプログラムの確かめ

C言語の落とし穴 MISRAに対応規則記述

Cコンパイラ自体のコンパイル

OSのソースのコンパイル TOPPERS


8

問題１From C Puzzle book© 1.1

#include <stdio.h>int main(int argc, const char * argv[]){

int x;x = -3 + 4 * 5 -6; printf("%d\n",x); //(1.1.1)11x = 3 + 4 % 5 - 6; printf("%d\n", x);//(1.1.2)1x = -3 * 4 % -6 / 5; printf("%d\n", x);//(1.1.3)0x = ( 7 + 6 ) % 5 / 2; printf("%d\n", x);//(1.1.4)1

return 0;}


問題１From C Puzzle book© 1.1

11

1

0

1


問題２From C puzzle book ©2.1 #define PRINT(format,x) printf(#x " = %" #format "\n",x)int integer = 5;char character = '5';char * string = "5”;int main(int argc, const char * argv[]){ PRINT(d, string); PRINT(d, character); PRINT(d,integer); //(2.1.1) PRINT(s, string); PRINT(c, character); PRINT(c,integer=53); //(2.1.2) PRINT(d, ('5' > 5)); //(2.1.3) { int x = -2; unsigned int ux = -2; PRINT(o,x); PRINT(o,ux); //(2.1.4) PRINT(d,x/2); PRINT(d,ux/2); //(2.1.5) PRINT(o,x>>1); PRINT(o,ux>>1); //(2.1.6) PRINT(d,x>>1); PRINT(d,ux>>1); //(2.1.7) return 0; }} 04/13/2023 (c)[email protected], @kaizen_nagoya 1

1

Defs.h(C puzzle book ©)

#ifndef puzzle4_1_defs_h

#define puzzle4_1_defs_h

#include <stdio.h>

#define PR(fmt,val) printf(#val " = %" #fmt "\t", (val))

#define NL putchar('\n’)

#define PRINT1(f, x1) PR(f,x1), NL

#define PRINT2(f, x1,x2) PR(f,x1), PRINT1(f,x2)

#define PRINT3(f, x1,x2, x3) PR(f,x1), PRINT2(f,x2,x3)

#define PRINT4(f, x1,x2, x3, x4) PR(f,x1), PRINT3(f,x2,x3,x4)

#endif 04/13/2023 (c)[email protected], @kaizen_nagoya 12

問題３

Puzzle book ©4.1#include "defs.h"int main(int argc, const char * argv[]){ int x, y=1, z; if( y!=0) x=5; PRINT1(d,x); //(4.1.1) if(y==0) x=3; else x=5; PRINT1(d,x); //(4.1.2) x=1; if(y<0) if (y>0) x=3; else x=5; PRINT1(d,x); //(4.1.3) if (z=y<0) x=3; else if (y==0) x=5; else x=7; PRINT2(d,x,z); //(4.1.4) if(z =(y==0))x=5; x=3; PRINT2(d,x,z); //(4.1.5) if(x=z=y); x=3; PRINT2(d,x,z); //(4.1.6) return 0;}


問題４

From Puzzle book© 6.1#include "defs.h”int i=0;int main(int argc, const char * argv[]){ auto int i=1; PRINT1(d,i);//(4.1.1) { int i=2; PRINT1(d,i);//(4.1.2) { i+=1; PRINT1(d,i);//(4.1.3) } PRINT1(d,i);//(4.1.4) } PRINT1(d,i);//(4.1.5) return 0;}


問題５From C puzzle book© 7.1

#include "defs.h" int a[] = {0,1,2,3,4};int main(int argc, const char * argv[]){ int i, *p; for ( i=0; i<=4; i++) PR(d,a[i]);//(5.1.1) NL; for(p=&a[0]; p<=&a[4]; p++) PR(d,*p);//(5.1.2) NL;NL; for(p=&a[0],i=1; i<=5; i++) PR(d,p[i]);//(5.1.3) NL; for(p=a, i=0; p+i<=a+4; p++,i++) PR(d,*(p+1));//(5.1.4) NL;NL; for( p=a+4; p>=a; p--) PR(d,*p);//(5.1.5) NL; for( p=a+4,i=0; i<=4;i++) PR(d,p[-i]);//(5.1.6) NL; for(p=a+4;p>=a;p--) PR(d, a[p-a]);//(5.1.7) NL; return 0;}


問題６Ｃプログラミングの落とし穴© 1.1章参考

#include "defs.h”

int main(int argc, const char * argv[])

{ int x = 1, y=0;

if (x = y) PRINT2(d,x,y);//Using result of an assignment as a condition without parentheses.

else PRINT2(d,y,x);

return 0;}04/13/2023 (c)[email protected], @kaizen_nagoya 1

6

問題７

Ｃプログラミングの落とし穴© 1.4章参考#include "defs.h”int main(int argc, const char * argv[]){ // insert code here... struct { int part_number; char * description; } parttab[]={ 046, "left-handed widget", 047, "right-handed widget", 125, "frammis" }; for (int i=0; i<3; i++){ PRINT1(d, parttab[i].part_number);

NL;PRINT1(s, parttab[i].description);} return 0;}


問題８

Ｃプログラミングの落とし穴© 3.8章参考#include "defs.h”int main(int argc, const char * argv[]){struct { int part_number; char * description; } parttab[]={ 046, "left-handed widget", 047, "right-handed widget", 125, "frammis" };

for (int i=0; i<3; i++){ PRINT1(d, parttab[i].part_number); NL;PRINT1(s, parttab[i].description);} return 0;}


問題 9

Ｃプログラミングの落とし穴© 4.4章参考#include "defs.h”int main(int argc, const char * argv[]){printf("%d\n",square(1.9));//implicit declaration of function// 'square' is invalid in C99 printf("%g\n",square(1.9));//Format specified type 'double //but the argument has type 'int’}int square(double x){ return (int) x*x;}


問題１０Ｃプログラミングの落とし穴© 6.2章参考

#include <stdio.h>

#define absm(x) x>=0?x:-x

int main(int argc, const char * argv[]){

int a=1, b=2;

printf("%d\n",absm(a-b));

return 0;

}04/13/2023 (c)[email protected], @kaizen_nagoya 2

0

問題の総括CPU, コンパイラによって振る舞いの違うコードが書けてしまう。　 ->未規定、未定義、処理系定義

可読性の悪いプログラムは、差分開発で書いた本人も間違える可能性がある

影響の範囲が特性しやすいプログラム

MISRA-Cに対応すると関数プログラミングに近づく


未定義 (undefined)と未規定(unspecified)

3.4.3 undefined behavior: behavior, upon use of a non portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on integer overflow.

3.4.4 unspecified behavior: use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any Instance

EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated.


課題の背景自称「 Cプログラマ」で C言語規格の存在、内容を知らない人がいる ?

WEBに審議文書を公開している開かれた規格。

http://www.open-std.org/itc1/sc22/wg14/

CPU、コンパイラによって振る舞いが違うコードの存在を知らない人がいる

プログラマが何でもできようにしてあるが、何をしたらいいかの知見をためるのがMISRA-C

http://researchmap.jp/kaizen/MISRA-C/


全問正解の方MISRA-C:2012の解説書を差し上げます。現在、構想。

MISRA-C 2013研究会解説書を作ろう


目的異なる CPUでコンパイルしたときに同じ振舞をする

安全なシステムを構築するための試験，証明。大規模化するソフトウェアの構造化。 CPUに依存した処理が書ける（高級アセンブラ）。

C言語教育に必要なこと。 Cコンパイラを理解する（改良できる）： C言語で記述 OSを理解する（改良できる）： C言語で記述ネットワークを理解する（改良できる）： C言語で記述

C言語試験、証明空間（集合）の制限：MISRA-C 時間の検証： HDLなら STARC RTL 設計スタイルガイド


25

C2011で嬉しいことA ｌ lignを規定した

GCCと Objective-Cで allignが違う。

Min-CAMLのコンパイルで失敗中。

Min-CAMLはアセンブラを出力している。

C言語を出力するようにすれば対応 CPUが増える。


MISRA-C 2012で嬉しいこと

C90, C99に両対応//コメント、 bool定義が基本。

規則の大分類を入れより体系的にDirective（指令）Rule(規則 )

検査しやすいように


ここで確認。1. C言語規格の審議過程（規格相当文書を含む）が閲覧できる

2. JIS 規格が無償で閲覧できる。

3. C言語には、 Cの精神、技術の発展のため、いろいろなことができるようになっている。

4. 自動車などの安全性の必要なプログラムは、できるだけ自由をなくして、なるべく唯一の方法をえらぶように習慣づける


MISRA-Cの確認Cプログラムが CPU、コンパイラで異なる振る舞いをすることを防ぎ、 CPU,コンパイラで同じ仕事をするようにする。

部分集合を定義しているので試験のしやすい、可読性の高いプログラムになる。

検査は複数の手段、道具を使うことを推奨している。 (合致表）

規則を守ることが大事なのではなく、なぜそうするとよいかどうかの判断ができる。規則を守ると

言語の Failure Modeをさける規則を列記しているのでソフトウェア FMEAの作業の最初として役立つ。 04/13/2023 (c)[email protected], @kaizen_nagoya 2

9

中間まとめC言語系のプログラマは C言語の脆弱性をよく理解するため、無料で手に入る C言語規格を利用しようできればＣコンパイラを書いてみると良い。オープンソースのＣコンパイラをいじるだけでもよいかも

MISRA-Cの検査の道具は無償のものは lintを拡張するするとよいかも

TOPPERSのオープンソースはMISRA-C 検査をして、逸脱の手続きを取っている。


ex2_1.c

検査結果 :提供者ヘッダファイルにも逸脱箇所あり。


31

逸脱の手続き 001


32

逸脱ルール

13: typedef shall be used instead of the basic types

逸脱箇所 193。チェッカで検査し、逸脱一覧を添付。

逸脱理由利用しない名前を付ける方が誤解を与える可能性がある。利用していない箇所の数を数えることで間違いの確認ができる。

対応する版 2011/7/8 以降の版

逸脱手順前回の検査時の数の変化の理由を確認し、担当者および確認者が署名またはソースの先頭に検査人の人名を入れる。

32

2011年 7月 8日、担当 :小川清、確認：、文書番号gifu2011001



33

逸脱ルール

14:use 'signed char' or 'unsigned char' instead of plain 'char’


逸脱理由ライブラリなどの複数箇所で利用している。部分的な修正の方が悪影響を与える。提供者と協議して書き換えるなら全部同時に実施する。それまでは現状維持。


逸脱手順前回の検査時の数の変化の理由を確認し、担当者および確認者が署名またはソースの先頭に検査人の人名を入れる。


33



34

逸脱ルール 69:ellipsis '...' shall not be used


逸脱理由提供側のヘッダファイルで規定しているため、ルネサスと協議するまで留保。


逸脱手順前回の検査時の数の変化の理由を確認し、担当、確認の 2名が署名。

34




35

逸脱ルール

113:struct/union members shall be named


逸脱理由利用しない値に名前を付けると間違えて使うといけない。


逸脱手順前回の検査時の数の変化の理由を確認し、担当者および確認者が署名またはソースの先頭に検査人の人名を入れる。 35


前提動的なメモリ利用は検証が困難

メモリ確保の時間は可変メモリ確保できるかどうかは可変メモリ解放がうまくいかずに、メモリ漏れ（ leak)

ポインタ操作の範囲確認が大変誤って命令、データを書き換え

CPU間のプログラムの移植の際に問題が発生16bit, 32bitunsigned, singed未規定、未定義，処理系定義


36

組み込みシステムハードウェアに近いところはＣ言語利用が多い

アセンブラも混在する場合ありC++はじめ他の言語の利用の場合もあるリアルタイム性が重要でない場合は JAVAなど

マイコン固有の機能の利用マイコン製造元が同時に C言語を出荷

Cコンパイラ自体、 C言語で記述Cの標準は特定の CPUを前提

16bit, 32bit安全性（信頼性） , 可搬性（移植性）


37

MISRA(Motor Industry Softwre Reliability Association)

MIRA( 欧州の自動車関連団体 :Motor Industry Research Association) Development guideline for vehicle based software （ ISO TR

15497:)

自動車用ソフトウェアの開発ガイドライン ( 自動車技術会 TP-01001) Guidelines for the use of the C language in vehicle based

software(MISRA-C:1998)

自動車用 C 言語利用のガイドライン（自動車技術会 TP-01002) C90対応解説書は SESSAME WG3 MISRA-C:2004(C90対応）


38

MISRA-C C言語規格の Portabilityに対する疑問から、 SaferCというより安全な C言語の書き方の提案があった

自動車業界の要請により自動車業界のコーディングルールとして 1998 年に発行。 HIS（ドイツの自動車業界団体）が Automotive SPICE(ISO/IEC 15504), ISO OSEK, ISO CANなどとともに採用

日本からの意見を含めて第二版を２００４年に発行

C99に対応した第三版を 2012 年に発行

(c)[email protected], @kaizen_nagoya

39

組込み研修04/13/2023

組込み開発者におくるMISRA-C組込みプログラミングの高信頼化ガイド

MISRA-C 研究会 (SESSAME WG3),日本規格協会 , 2004

C言語で書いたソフトウェアを他の CPUに移植する際に問題となる事項を洗い出し C言語の規定のあいまいな事項を排除して、不具合を減らす

参考文献 Safer C C言語の落とし穴


40

MISRA-C:1998 の概要 127項目の具体的なプログラミングルールと品質サブシステムの解説静的テストが可能なもの中心 93の必要と 34の推奨

規格 (C90)を基準として利用


41

MISRA-C:1998の特徴 MISRA-Cの合致は製品ごと

コードの書き方だけでなく、検証方法を要求（合致マトリックス）

守らない方がよい規則は逸脱の手続き

静的検査ツールによる検出を重視静的なプログラムを推奨

メモリの動的確保はしないポインタの演算はしない


42

MISRA-C適用における注意事項

ISO/IEC 9899-C languageについてメトリクスについてサブセットの導入ルールからの逸脱について必要ルールと推奨ルールについて ISO/IEC Cの附属書 Gについてハードウェア制御と文法再定義について副作用と副作用完了点についてビットフィールドについて


43

MISRA-Cの利用方法テスト仕様書の一部

品質指標を明確化

グローバルに対応

言語教育に利用

規則の取捨選択 Standing Deviation

静的検査ツールの利用


44

規則の分類（カテゴリ）環境文字セットコメント識別子型定数宣言と定義初期化

演算子変換式制御フロー関数前処理指令ポインタと配列構造体と共用体標準ライブラリ


45

課題の段階的詳細化安全なシステムを構築するために、何ができるか。

ハードウェアとソフトウェアの責任境界の明確化〔対応）大規模化するソフトウェアで、何が必要か。

共通の規則（一部対応）高級アセンブラとして CPU に依存した処理が書ける C 言

語には何が必要か。依存した部分の文書化（対応）

C 言語の教育に必要なことは何か。動くプログラムで教育（応用）

C 言語の試験に必要なことは何か。試験をしてからプログラム || 試験のためのプログラムから出発（応

用）


46

ハードウェアとソフトウェアの責任境界の明確化

C言語の Portabilityにハードウェアとの責任境界が見える

CPUごとの試験

Cコンパイラの試験

OSの試験


47

プログラムの安全性コンパイラ、チェッカ（静的解析ツール）で検査可能かルールを守らない方が安全な場合は逸脱の手続きを取る警告が多いと見逃しがでるため、チェッカが逸脱の手続きと連動しているとよい警告のノイズ

真の警告ではないチェッカの不具合逸脱した方が品質が高い１つの事象に複数の警告がでる（一番優先順位の高いものだけでよいかも）

ハードウェアと関係した試験とソフトウェアだけでできる試験を分ける


48

共通の規則（一部対応）作業標準

ISO TR 15497（MISRA-SA) スタイルガイド

アプリケーションごとプログラミング言語ごと

命名規則 OSごとアプリケーションごとプログラミング言語ごと

言語に依存したコーディングルール MISRA-C


49

依存した部分の文書化 MISRA － Cの逸脱の手続き

規則を守るのがよいとは限らない処理速度の低下コードの移植性の低下

規則の逸脱する方がよい場合がある形式的な規則の適用の危険性例：

アセンブラのソースコード複数箇所からの戻り


50

OSとコンパイラ C言語がＯＳの存在を想定している場合と、ＯＳがない場合の２つの標準 Host 環境 Freestanding 環境

ＯＳの存在を想定している場合には、ＯＳの規定が優先文字コード、改行、エスケープシーケンス

クロス開発の場合には、開発用ＯＳと対象ＯＳの違いに留意

コンパイラによる動作の違い


51

動くプログラムで教育（応用）

C Puzzle Bookトリッキーなプログラムの確かめ

C言語の落とし穴 MISRAに対応規則記述

Cコンパイラ自体のコンパイル

OSのソースのコンパイル


52

試験をしてからプログラム試験のためのプログラムから出発

最初は試験プログラムを書く

CPUの試験、 Cコンパイラの試験、 OSの試験、ライブラリの試験から始める

試験プログラムを書くことにより、試験可能なプログラムが書けるようになるかも

可搬性のあるプログラムを書けると再利用可能性が高くなるかも


53

MISRA-C 環境 1 (必須 )全てのコードは ISO

9899 C標準を満たしていなければならず , 拡張機能は許されない。

3 (推奨 )Cから呼び出されるアセンブリ言語の関数は , インラインアセンブリ言語のみが含まれている Cの関数として表現されなければならず , インラインアセンブリ言語は一般の Cコード内に組み込まれてはならない .

5 (必須 )ISO C標準で使用されている文字や拡張表記のみ使用可能である . 8 (必須 )マルチバイト文字や拡張文字列リテラルは使用してはならない .

コメント 9 (必須 )コメントは入れ子であってはならない .

10 (推奨 )コード部は‘コメントアウト’してはならない .

関数82 (推奨 ) 関数は 1つの出口しか持ってはならない .


54

MISRA-C対応の事前準備処理系定義 (ImplemantationDefinition)を確かめる

コンパイラ、 OSを試験する有効なルールか、現実ありそうなことかを確かめる

コンパイラによる違い。ＯＳの違い。ルール間の矛盾がないかを確かめる

ルール１を守ると、自動的に守れるルールルール１を逸脱しているルールルール（ Cの規格の規定）間の優先順位

ＭＩＳＲＡ -Cの教材動く事例 OS、コンパイラのソースをチェック記録

合致マトリックスの作成逸脱の手続きの作成


55

例題定義文書の例題は、コンパイルできるソースコードではない。

【サンプル】[ 例 ]UI_8 var1 = '\377'; /* OK: 8進拡張表記 \377は 10進の 255 */UI_8 var2 = '\0'; /* OK: 8進拡張表記 \0は 10進の 0 */ /* (\0は一般にナル文字を表すために使用する ) */UI_8 var3 = '\xFF'; /* OK: 16進拡張表記 \xffは 10進の 255 */UI_8 var4='$';/* NG:$は定義されていない文字なので , 未定義の動作となる */UI_8 var5='@';/* NG:@は定義されていない文字なので , 未定義の動作となる */UI_8 var6='\C';/* NG: \Cは定義されていない拡張表記なので , 未定義の */ /* 動作となる */


56

例題実行方法

１： Windows/Linux 上のコンパイラでのシュミレーション stdio.h を利用

printf 関数 main 関数

処理結果と処理経過を表示利用したコンパイラ

Microsoft VisualStudio 6.0 (Cygwin/Linux) GCC 3.1.x/GCC 3.4.X

２： M32C,TOPPERS/jsp タスク monitor タスクを利用

Printf 相当の関数ありコンパイラ : ルネサス製 N308

MISRA-C チェッカあり


57

misra.h

/********************************* File Name: misrac.h* Author: kaizen ＠ wh.commufa.jp* Date: 2004.07.20* Version: 0.09* Purpose: Test Use Only.* Distributer:SESSAME WG3/ MISRA-C Study Group sub-group x*******************************/#define _misrac_h_/* TOPPERSでコンパイルする場合は _TOPPERS_を宣言しておく。それ以外はDOS 相当のOSでの動作。 */


58

#ifdef _TOPPERS_#include "../include/misrac_toppers.h"#else#include "../include/misrac_dos.h"#endif /* _TOPPERS_ */

#ifndef __STDC__#ifdef DEBUG#error __STDC__ is not defined.#else#define __STDC__ 1#endif /* DEBUG */#endif /* __STDC__ */

プログラムの書式 header: author, Create date, Update dateRule: Rule #, rule(Japanese and English)Body:#inclue <misrac.h>…Result: Visual Studio　 (microsoft), GCC, N308(Renesas Technology)Footer: update log


59

Rule1.c

*****************************/

* File Name: rule1.c

* Author: kaizen ＠ wh.commufa.jp

* Date: 2004.09.14

* Version: 0.04

* Purpose: Test Use Only.

* Ruel section

Rule1:すべてのコードは ISO/IEC 9899:1990 を満たしていなければならず , 拡張機能は許されない .

* [MISRAC開発ガイドラインテーブル 3]

original Rule 1: All code shall conform to

ISO 9899 standard C,with no extensions

permitted.

**************************/

#define _rule1_c_

#include “../include/misrac.h”


60

/******************************* output section* Visual Studio 6.0 : no error, no warningmain START far_ptr_arg = 4198400pointer = 4198912near_ptr_arg = 4198912si32_var = -512main END * gcc 3.3.1 (cygwin) : no error, no warningmain START far_ptr_arg = 4198581pointer = 4198828near_ptr_arg = 4198828si32_var = -247main END * End: rule1.c (C) MISRA-C Study Group Japan* add result 2004.07.14* add end-result and rule 2004.09.14*****************************/

rule5

* rule 5: ISO C標準で使用している文字や拡張表記のみ使用可能である .

* original rule 5: Only those characters and escape sequences which are defined in the ISO C standard shall be used.

UI_8 ui8_var4 = '$'; /* NG: $は定義されていない文字 */UI_8 ui8_var5 = '@'; /* NG: @は定義されていない文字 */UI_8 ui8_var6 = ‘\C’; /* NG: \Cは定義されていない拡張表記 */

Ｃ標準で使用していない文字を認識。 OSで規定すべきこと ->OS ごとに Standing Deviationを規定するとよい。


61

rule8

Visual Studio では、「適合していないﾜｲﾄﾞ文字列を連結しています。」と出たが、 gcc(cygwin)では、出なかった。

WC_T wct_ary[] = "abc" L"ABC";

/* NG: 潜在的問題 (5)( 補足参照 ) */


62

対応ツール QAC

PolySpace Verifiler

C++TEST

PG Relief C/C++

LDラテストスイート

Review C

SQMlint


63

C99未対応 (1998/2004 年版）

MISRA-C:1998 ， 2004とも //コメントを認めていないコメントの便利さと危険性

C99未対応の理由 C99対応コンパイラが少ない C99に詳細な規定が多い


64

MISRA-C1998 まとめ安全なシステムを構築するための、試験を前提としたコ

ーディング規則大規模化するソフトウェアで、命名規則と直交できるコ

ーディング規則 CPU に依存した処理の切り分け C 言語の教育には OS 、 C 言語のソースコードのコンパ

イルを含む、現実の問題との対応開発の最初から試験を行う


65

MISRA-C1998 課題 MISRA-C 2004

C99 未対応 C99 の不要な規定の除外または改定要求

OSの有無、種類による standing deviation

16bit, 32bitの固有の問題の識別 (8bit, 64bit)

安全性の程度による適用


66

MISRA-C(2004)ガイド

SESSAME WG3（MISRA-C研究会）

IEC61508/ISO26262に基づくサブセット、ガイドラインとして利用

1998年版に対する日本(MISRA-C研究会）からの意見採用

ルールの厳密化 1998: (推奨)コード部は‘コメントアウト’してはならない.

2004:コメントの中で/*を書いてはいけない

ルール数の増加厳密にしたため、あいまいなルールが詳細なルールになる

不要なルールの削除多言語のコメントの使用禁止


67

©MISRA-C研究会

MISRA-C ：品質の視点品質確認の文書化

規則としての文書化 3.1 処理系定義の動作はすべて文書化 3.2 文字集合及び円コーディング 3.3 整数除算の実装 3.4 #pragma命令 3.5 ビットフィールド 3.6 ライブラリ

逸脱の手続きとしての文書化品質確保の技法例：

9.1すべての自動変数は用いる前に値を代入しなければならない。 14.1 到達しないコード 21.1 実行時の誤り


68

規則 9.1 変数の初期値

すべての自動変数は用いる前に値を代入しなければならない。


69

void func(void){int16_t s16_var1 =0;int_16_t i ;for(i=0; i<3; i++){

s16_var1+=i;}

}

©MISRA-C研究会

組込み研修 (c) saito.naoki, ogawa.kiiyoshi

規則 14.1 到達しないコード

到達しないコードがあってはならない。

エラー検出のためのコードを埋める場合には、逸脱の手続きを取る。逸脱がある程度あるものが品質が高い可能性がある。

工業標準利用時の経験則（ベストプラクティス）


70

int_32t s32_inc(int32_t i){i++;return i;

print_error(UREAC) ；}

©MISRA-C研究会


71

参考文献 The Motor Industry Software Reliability Association(1994):Development

Guidelines for Vehicle Base Software,ISBN 0952415607 The Motor Industry Software Reliability Association(1998):Guidelines for

THE USE Of The language IN Vehicle Based Software ISBN 0952415690 Guidelines for the use of the C language in critical systems, 2013, ISBN

9781906400-11-8 PDF JSAE(2002):JASO/TP-01001 自動車用ソフトウェアの開発ガイドライン , 社団法人自動車技術会

JSAE(2002):JASO/TP-01002 自動車用Ｃ言語利用のガイドライン、社団法人自動車技術会

B.W. カーニハン ,D.M.リッチー著 , 石田晴久 ( 訳 :1989)プログラミング言語Ｃ、共立出版

Ａ .コーニグ著 .中村明 ( 訳 :2004） Cプログラミングの落とし穴 ,新紀元社

アラン・ R. フューアー著 , 田中和明・手塚忠則 ( 訳 :2000)C PuzzleBook, カットシステム

履歴 2007年 6月組込み研修で利用

2007年 9月電気関係学会東海支部で発表課題

項目数の評価 ETSS利用による効果測定

2007年 11月組み込み Linux研修

2008年企業向け研修

4.1 2009年 SPIN研修

4.2 2009年MISRA-C++研修

4.3 2009年組込み研修


72

謝辞OSC 事務局SESSAMEプロジェクトTOPPERSプロジェクト組込中核人材プロジェクト東陽テクニカ日本規格協会ISO/IEC JTC1 SC22 WG14

自動車技術会トヨタ自動車C Puzzle Book

Cプログラミングの落とし穴


Documents

MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013