Who enjoy a coding standard?

コーディング標準は誰のため？
（発表はCおよびC++質問他言語可）

技術士（情報工学）・工学博士　小川清
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

「The C Puzzle Book」, 「Cプログラミン
グの落とし穴」を出発点に
ISO/IEC9899/14882, MISRA C/C++,
CERT C/C++, ISO/IEC TS17961,
コード断片・例題をコンパイルしよう！ 


https://www.tiobe.com/tiobe-index/
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 4

https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017

規則を守れ!

コーディング標準は
規則だから守れ！


何のために？


可読性が高まる？
可読性や保守性を高めるためにコー
ディングルールはちゃんと決めよう
https://mbdb.jp/adversaria/coding-
rule.html

CERT C++ DCL60-CPP.
Obey the one-definition rule
https://wiki.sei.cmu.edu/confluence/
display/cplusplus/DCL60-CPP.
+Obey+the+one-definition+rule

可読性上がった？

品質統一
コーディング規約の作り方の基本とメ
リット・デメリット　@フリエン
https://furien.jp/columns/185/#2

コーディング規約を守っ
ても、いくらでも品質の低
いプログラムは書ける。


コーディング規則を守
るための書き換えた
方が品質が下がるこ
とがある


namespace、私が規格のコード断
片コンパイルしているときに使っ
ている方法と同じ

複数のコード断片で、同じ
変数を使っている場合
•  変数を変更していた
•  見た目が変わるのは理解の妨げになる
•  違う関数の中に入れていた
•  関数の中に入れられない記述もある
•  Namespaceで区分
•  それでも影響がある場合は、ファイル分割
•  C++ N4606 のコード断片をコンパイルするためにしていること
•  https://qiita.com/kaizen_nagoya/items/a8d7ee2f2e29e76c19c1

根拠のないコ
ーディングルー
ルは害悪

/**/コメントと//コメント
  STARC RTL設計スタイルガイド
verilog HDL編では//コメントを推奨
  MISRA C 1998, 2004では//コメントを
禁止
  どっちが品質に悪い影響を与えやす
いかは自明？

未定義、未規定はC言語発
展の余裕で悪者ではない
品質を上げるために未定義、
未規定の処理を定義して使
うのは良いこと。使わないこ
とは品質を上げない。

規則を守るた
めだけの書き
換えは最悪

書き換える前と
後で複数の品質
指標で測って選
択しよう

品質指標の候補
 文字数
 変数数
 名前の類似度と意味の類似
度の相関
 条件分岐の複雑度

コーディング標準
は何のため？

言語仕様の部分集合を定義
  試験範囲を狭める
  試験容易性を高める
  どのチップ、どのコンパイラでも実現している共通部
分を確認
  未定義、未規定でも、チップ、コンパイラが違っても同
一であればよい
  将来の規格で定義、規定の提案をすればよい

逆に
 規則を守るために品
質を落とす書き換え
は最低

じゃどうすればいいの

MISRAでは逸脱の手
続きを規定

でも、逸脱手続きに手間がか
かるのは嫌

簡単な逸脱方法が大事
  逸脱する処理だけ、小さな関数にまとめる
  アセンブラを用いる場合も関数の形にする
  逸脱する部分を、区分するか註釈をつける
  検査する道具(checker)で逸脱の確認、文書化を自動化

逸脱すると受け取った側も確認
が必要になるとの思い込み

逸脱していなくても確
認は必要

逆に

逸脱がない場合の方が品質
が低い可能性があるとして検
査を強化した方が良いかも。

理想論？

確かに
なるほど
そうですね

じゃ、どうすりゃいいの？

手順案
  プログラマは自由に書く
  Review前に整形の道具で清書する
  静的検査の道具にかける
  命名規則の検査の道具があればかける
  修正は最初は品証部門がしても良い
  品質を下げる書き換えはせずに逸脱の手続きを取る
  害のあるコーディングルールは変更する
  この方法で何度かReviewするとプログラマも規則に沿った書き方
のうち、自分でも対処したくなる事項がいくつか出てくる

プログラマが楽できる規則は守る、
楽できない規則は守らない
または
道具でできることは道具に任す

逸脱の手続きは品質が高い
ことを示すための資料


でも、わざと逸脱することは
できる

やっぱりプログラマを信用す
るしかないのか

続く

コーディング標準はプログラ
マを縛るか？

運用次第

プログラマは自由に書
いて、 Review前に道
具にかければ良い。

２、３回は品質
部門が書き直し
ても良い。

例：タブ
2tab, 3tab, 4tab, 6tabどれで
書いても、Review前に道具で
その会社のタブすうに変換す
れば良い。

なんどもReviewしていると、そ
の会社でコードを見るのは何
タブがいいか、次第に意見が
収束してくるかも。

例：Qiitaに上げる前に利用し
ているスクリプト
空白2つのタブに変更
  #!/bin/bash
astyle -s2 -c < $1.cpp > $1s2.cpp
  cat $1s2.cpp

おまけ
  今困っていること
  namespaceのカッコの
中のタブ（空白）を生
成しない。オプション
未調査。

namespace M {
  class B { };
  }
  namespace N {
  class Y : public M::B {
  class X {
  int a[i];
  };
  };
  }
int main() {
  cout<< msg << endl;
  return EXIT_SUCCESS;
  }

これまでやってきたこと
  ISO/IEC 9899:1990(ANSI C:1989)にどのコンパイラがどれほど適
合しているかの試験
  C puzzle bookを利用したprintfによる仕様の曖昧さ、誤解の確認
  MISRA-Cの解説書作成への参加とMISRAへの改定への意見の提
出
  ISO/IEC JTC1 SC7からISO/IEC JTC1 SC22へのリエゾン

ISO/IEC 9899:1990(ANSI C:
1989)にどのコンパイラがどれ
ほど適合しているかの試験

Watcom Cが一番細かいところまで適合していた
  現在、Open Watcomが公開されている。
  ISO/IEC 9899:1990の16bit試験ならOpen Watcomが
お勧め

C puzzle bookを利用した
printfによる仕様の曖昧さ、誤
解の確認
 出力しようとすると、新たな
コンパイルエラーに遭遇
  C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性
を認識
  https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9

$ clang++ err3.cpp -std=c++2a -Wall
  err3.cpp:34:6: error: invalid operands to binary
expression ('std::__1::ostream'
  (aka 'basic_ostream<char>') and
'AlignedUnion<int, char>')
cout << au << endl;
  ~~~~ ^ ~~
  ^
  この後、このエラーだけでMSGが170行続く

自己紹介
  VZエディタN5200移植
Minix手引書作成・配布
  大学PC用通信エミュレータ移植
  連立微分方程式の解法(Pade近似）
  プログラムジェネレータの自己生成
  UNIX版FD作成
  OBJシンタックスチェッカ作成
  Mobile IPを利用した経路選択のた　
めのパケット計測
岐阜大学非常勤講師
JAXA/IPA WOCSプログラム委員長
情報処理学会情報規格調査会
SC7WG10,20,24委員
SESSAME/MISRA　C研究会
TOPPERSプロジェクト理事
IPA/SEC連携委員
2018/05/1
9
(c)kaizen@wh.commufa.jp,
@kaizen_nagoya

本日の想定する道具(compiler)
gcc, g++(32/64bit)
  clang,clang++(LLVM)(32bit/64bit)
  http://clang.llvm.org
  Open Watcom(16bit/32bit)
http://sourceforge.net/projects/openwatcom/
  Visual C/C++(2017)

Visual Studioのコマンドコンパイル
  プログラムメニュー
  Microsoft Visual Studio .Net 2XXX
  Visual studio .NETツール
  Visual studio .NET 2XXXコマンドプロンプト
  copy con a.c
  ^Z
  cl a.c
a.exe


14:00-14:10演習0: /主要文献
  14:10-14:20演習1:
  14:20-14:30 答合せ
  14:30-14:40演習2:
  14:40-14:50 答合せ
  14:50-15:00演習3:
  15:00-15:10 答合せ
  15:10-15:20演習4:
  15:20-15:30　答合せ
2018/05/19
@kaizen_nagoya
15:40-15:50演習5:
15:50-16:00 答合せ
16:00-16:10演6:
16:10-16:20 答合せ
16:20-16:30
16:30-16:40 逸脱の手続き
16:40-16:50演習7:
と質疑応答
16:50-17:00 今後の課題

ISO/IEC 9899の３つの版の集合関係を示しなさい。
1990(C90/ANSI C 89), 1999(C99), 2011(C2011)
  MISRA Cの３つの版の集合関係を示しなさい。
1998,2004,2012
  ISO/IEC 9899とMISRA Cの集合関係を示しなさい。
  ３つのコーディグ標準(CERTC, ESCR, ISO/IEC TS
17961)の集合関係を示しなさい。

Brian W. Kernighan and
Dennis M. Ritchie(K&R)
  利点
  簡単に動くソフトウェア
main(){
printf(“Hello World!¥n”);
}
  罠
  ２つとも可変引数関数（）
  初版1978
  日本語版には「UNIX流プログラム書法と作法」
  ANSI-C対応版1988
  #include <stdio.h>

C言語と規約の歴史
  1978 K&R The C programming Language(Bell Lab.)
  1982 The C Puzzle Book(Bell Lab.)
  1988 K&R ver.2(ANSI-C version: Bell Lab.
  1989 C tarps and pit falls(Bell Lab.)
  1989 ANSI-C:1989
  1990 ISO/IEC 9899(same as ANSI-C)
  1995 Safer C
  1995 ISO/IEC 9899 Amd1
  1998 MISRA C:1998
  1999 ISO/IEC 9899
  2004 MISRA C:2004
  2011 ISO/IEC 9899
  2012 MISRA C:2012

The C Puzzle BOOK
by Alan R. Feuer
  利点
  ソースコードと出力例・解説
がある。
  Bit幅などにCの処理系による
違いがわかる。
  初版1982, 改訂版1998
  Bell Laboratory

C traps and pitfalls
by Andrew Koenig
  利点
  プログラマが遭遇する怪しいプログラム
例
  MISRA Cで参照・引用
  if (x = y) foo();
  Newsletter :ACM SIGPLAN Notices:
http://www.literateprogramming.com/
ctraps.pdf The C Puzzle Bookが参考文献。
  1995
  Bell Laboratory2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

Safer C developing software
for high-integrity and safety-
critical systems.by Les Hatton
  規格の未定義、未規定、処理
系定義による動作の違いの
可能性を指摘
  処理系による動作の違いを避
けるプログラミング
  1995
  http://www.leshatton.org

MISRA C-Training Kit内訳 

The C Puzzle Book/C traps and pit falls
ISO/IEC 9899:2011(1999, 1995, 1990)
ESCR
ISO/IEC TS 17961
CERTC
MISRA C2012, 2004, 1998

2018/05/19
@kaizen_nagoya
•  資料のソースコードの断片を単独のプログラムで出力。
•  例：The C Puzzle Book, HOST環境で試験。
•  共通のヘッダファイルを定義。
•  複数のコンパイラ、複数のC標準対応(C90,C99,C2011)
のコンパイルはバッチファイル(shell script)。
•  適合の例と非適合の例を条件コンパイル。
•  コンパイルできることを優先。
•  コンパイルエラーになることあり。
•  警告はなるべくたくさん出す。
•  出力で振る舞いを確認。
•  規則名・対応標準出力。

2018/05/19
@kaizen_nagoya
•  ファイル名、作成月日、作成者
•  #ifndef __MISRA_C__
•  #define __MISRA_C__
•  #include <System header file>
•  C標準対応(C90,C99)
•  個別の規則ごとの定義

2018/05/19
@kaizen_nagoya
•  #include “header.h”
•  C標準対応(C90,C99)
•  規則名
•  #define RULE “Rule sentence or Rule name¥n”
•  printf(RULE);
•  個別の規則ごとの定義

2018/05/19
@kaizen_nagoya
•  Echo ‘コマンド出力’
•  C標準対応(C90,C99,C2011)
•  C90用に//コメントを/* */コメントに変換
•  複数のコンパイラ
•  GCC
•  LLVM(Clang)
•  Open Watcom(16bit/32bit)
•  Visual C
•  マクロ展開
•  適合例と非適合例の別コンパイル )

2018/05/19
@kaizen_nagoya
•  Rubyのスクリプト
•  コンパイル前にバッチファイルから呼び出す
•  //コメントを/* */コメントに変換
•  制約条件
•  一行に両方の形式で記述しない。
•  コメントの中にコメントを書かない
•  Header.hは/* */形式のみ（変換の手間を省く）
•  最初から記述している/* */コメントは行の先頭からだと
後々コンパイルエラーの原因にならない。

動くプログラムで教育
l  The C Puzzle Book
l  危険なプログラムの確かめ
l  Cプログラミングの落とし穴
l  MISRAに対応規則記述
l  Cコンパイラ自体のコンパイル
l  OSのソースのコンパイル
l  TOPPERSのMISRA C対応
l  国際規格・コーディン
グ標準の例(sample)の
コンパイル

問題１ The C Puzzle book© 1.1

#include <stdio.h>
int main(int argc, const char * argv[])
{
int x;
x = -3 + 4 * 5 -6; printf("%dn",x); //(1.1.1)11
x = 3 + 4 % 5 - 6; printf("%dn", x);//(1.1.2)1
x = -3 * 4 % -6 / 5; printf("%dn", x);//(1.1.3)0
x = ( 7 + 6 ) % 5 / 2; printf("%dn", x);//(1.1.4)1
return 0;
}

問題１
From C Puzzle book© 1.1
11
1
0
1
http://researchmap.jp/jo1lnydjn-1797580/

問題２ The 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;
}
} 2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

参考：defs.h(TheC 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

問題３ The
C 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;
}

問題４ The
C Puzzle
Book ©6.1
#include "defs.h”
int i=0;
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;
}

問題５ The
C puzzle
book© 7.1
#include "defs.h”
int a[] = {0,1,2,3,4};
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 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;
}

#include "defs.h”
// 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;
}
2018/05/19
@kaizen_nagoya
問題６Ｃプ
ログラミング
の落とし穴©
1.1章参考

問題７
Cプログラミング
の落とし穴©
1.4章参考
#include "defs.h”
// insert code here...
struct {
int part_number;
char * description;
} parttab[]={
125, "frammis"
};
for (int i=0; i<3; i++){
}
return 0;
}

#include "defs.h”
struct {
int part_number;
char * description;
} parttab[]={
125, "frammis"
};
for (int i=0; i<3; i++){
}
return 0;
}
問題8 Ｃプロ
グラミングの
落とし穴© 3.8
章参考

問題9 Ｃプログラミングの落
とし穴© 4.4章参考
#include "defs.h”
printf("%dn",square(1.9));//implicit declaration of function
// 'square' is invalid in C99
printf("%gn",square(1.9));//Format specified type 'double
//but the argument has type 'int’
}
int square(double x){
return (int) x*x;
}

問題10 Ｃプログラミングの落
とし穴© 6.2章参考
#include <stdio.h>
#define absm(x) x>=0?x:-x
int a=1, b=2;
printf("%dn",absm(a-b));
return 0;
}

問題の総括
  CPU, コンパイラによって振る舞いの違うコードが書
ける。　->未規定、未定義、処理系定義
  可読性の悪いプログラムは、差分開発で書いた本人
も間違える可能性がある
  影響の範囲が特定しやすいプログラム
  MISRA Cに対応すると関数プログラミングに近づく
  副作用が処理系定義などのため、副作用を避ける

Ｃ言語の規格
l  K&R(de facto)C言語作者の文書
l  アメリカ規格(de jure)
l ANSI X. 1989(C89):1999版からISO/IECと同時進行
l  国際規格:フリースタングィング環境(main無可)，ホス
ト環境（main引数有）
l ISO/IEC 9899:1990(C90=ANSI C89)
l  AMD 1995
l ISO/IEC 9899:1999(C99)
l ISO/IEC 9899:2011(C2011)
l  国内規格
l JIS X 3010:1993(C90), JIS X 3010：2004(C99)
l  最新版はwww.jisc.go.jpで無償で閲覧可

ISO/IEC 9899:2011
  審議文書をISO/IEC JTC1 SC22 WG14からダウンロード可能
  http://www.open-std.org/JTC1/sc22/wg14/www/standards.html

ESCR
  IPAから英語版はダウンロード可能
  http://www.ipa.go.jp/files/000040508.pdf

ISO/IEC TS17961
  審議文書をISO/IEC JTC1 SC22 WG14からダウンロード可能
  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1624.pdf
  CERTCから厳選

CERTC
 英語・日本語とも公開
https://www.securecoding.cert.org/
confluence/display/seccode/
CERT+C+Coding+Standard
  参考文献（英語）URL: 鋭意更新中

MISRA C:2012
  PDFで購入してもソースをテキスト出力できない
  MISRAの掲示板にサンプルスイートあり。
  掲示板　http://www.misra.org.uk/forum/index.php
サンプルはリソース欄に。　http://www.misra.org.uk/forum/
viewtopic.php?f=149&t=1340
  コンパイルエラーの有無の確認ができる。
  実行を確かめる仕組みになっていない。

ここまでのまとめ
  The C puzzle BOOK, C Trap and pitfallsなどの困ったプ
ログラムを排除する規約
  国際規格ISO/IEC 9899の例をコンパイル
  Undefined, Unspecified, Implementation defined
  CERTCとTS17961は姉妹
  Library, OSとの境界に着目
  MISRA C

背景・根拠・経緯
•  C言語の習得は、コンパイルコンパイルコンパイル。
•  C beautifierのソースコードでC言語の勉強をした。
•  Cで書かれたSmallCという小さいコンパイラを入力してコン
パイルエラーがでなくした。
•  Pascalで書かれていたコンパイラをCに書き直した。
•  OBJのシンタックスチェッカを書いてみた。
•  Yacc, Lexを使ってコンパイラを作ってみた。
•  C++, JAVAも多くの教材をコンパイルしてみると、OS・コン
パイラの版・英日による違いが多数。
•  シミュレータ・コンパイラ自身をC言語で記述し、コンパイラ
にかけている。

今頃C言語？
•  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: 天才の書いたプログラムを、凡人が間違ったプログラムにしてし
まうことがある。凡人にも理解出来るコードが書けるのも天才の
技の一つ。

背景
l  CPU販売者が言語としてアセンブラとCを提供。
l  CコンパイラもCで記述
l  CPUの発展を阻害しないように、Cプログラマに不必要な
負荷をかけないように(Cの精神:the spirit of c）、C言語
規格には「未規定」，「未定義」，「処理系定義」がある。
l  C言語規格には
l  OSの存在を前提としたホスト環境（OSあり,mainあり）と
l  OSの存在を必ずしも想定していないフリースタンディング
環境とがある。OSなくてもよくMainは必要ない。
l  C言語規格にはOSの一部かもしれないライブラリがある。
l  OSもCで記述

JIS C解説(Cの精神）　© JIS
1.既存のコードを救うことが重要であり、既存の処理系を保護すること
は、重要視しない。
2.可搬性のある原始プログラムが書けるようにする。 (高級アセンブラ
的な使い方による）可搬性がないプログラムを禁止してはならな
い。
3.(既存の仕様からの）暗黙の意味変更（quiet change)は極力避ける
4.規格は処理系の作成者とプログラマとの間の約束事を記述するもので
ある。
5. 次のCの精神を遵守する.
1.  プログラマを信頼する
2.  プログラマが必要である事項を行うことを妨げない
3.  言語は小さく、コンパクトに保つ
4.  一つのオペレーティングシステムには唯一の方法を割り当てる
たとえ可搬性が保障されない方法であったとしても、実行効率を上げ
る余地を残しておく。

The spirit of C, Additional Principles for C1X
ISO/IEC JTC1 SC22WG14 N1250
12. 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.

未定義(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言語規格の存在、内容を知らない人がいる。
CPU、コンパイラによって振る舞いが違うコードの存在を知らない人
がいる
→　WEBに審議文書を公開している開かれた規格。
http://www.open-std.org/itc1/sc22/wg14/
C言語はプログラマが何でもできようにしてあるが、何をしたらいい
かの知見をためるのがMISRA C
　　→　http://researchmap.jp/kaizen/MISRA C/


目的
l  異なるCPUでコンパイルしたときに同じ振舞をする
l  安全なシステムを構築するための試験，証明。
l  大規模化するソフトウェアの構造化。
l  CPUに依存した処理が書ける（高級アセンブラ）。
l  C言語教育に必要なこと。
l  Cコンパイラを理解する（改良できる）：C言語で記述
l  OSを理解する（改良できる）：C言語で記述
l  ネットワークを理解する（改良できる）：C言語で記述
l  C言語試験、証明
l  空間（集合）の制限：MISRA C
l  時間の検証：HDLならSTARC RTL設計スタイルガイド

ISO/IEC 9899:2011で嬉しいこと
  Aｌlignを規定した
  GCCとObjective-Cでallignが違う。
  Min-CAMLのコンパイルで失敗中。
  Min-CAMLはアセンブラを出力している。
  C言語を出力するようにすれば対応CPUが増える。

MISRA　C 2012で嬉しいこと
  C90, C99に両対応
  //コメント、bool定義が基本。
  規則の大分類を入れより体系的に
Manatory
  Directive（指令）
  Rule(規則)
  ツールで対応可能かどうか。
  Decidable, Undecidable
  検査しやすいように

ここで確認。
1.  C言語規格の審議過程（規格相当文書を含む）が閲
覧できる
2.  JIS 規格が無償で閲覧できる。
3.  C言語には、Cの精神、技術の発展のため、いろいろ
なことができるようになっている。
4.  自動車などの安全性の必要なプログラムは、できる
だけ自由をなくして、なるべく唯一の方法をえらぶよ
うに習慣づける

MISRA Cの確認
  CプログラムがCPU、コンパイラで異なる振る舞いをする
ことを防ぎ、CPU,コンパイラで同じ仕事をするようにする。
  部分集合を定義しているので試験のしやすい、可読性の
高いプログラムになる。
  検査は複数の手段、道具を使うことを推奨している。(合
致表）
  規則を守ることが大事なのではなく、なぜそうするとよい
かどうかの判断ができる。規則を守ると
  言語のFailure Modeをさける規則を列記しているのでソフ
トウェアFMEAの作業の最初として役立つ。

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

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

逸脱の手続き001
逸脱ルー
ル
13: typedef shall be used instead of the basic
types
逸脱箇所 193. チェッカで検査し、逸脱一覧を添付。
逸脱理由
利用しない名前を付ける方が誤解を与える可
能性がある。利用していない箇所の数を数え
ることで間違いの確認ができる。
対応する版 2015/5/8以降の版
逸脱手順
前回の検査時の数の変化の理由を確認し、担
当者および確認者が署名またはソースの先頭
に検査人の人名を入れる。
113
2015年5月23日、担当:小川清、確認：X、文書番号gifu2015001

逸脱ルー
ル
14:use 'signed char' or 'unsigned char'
instead of plain 'char’
逸脱理由
ライブラリなどの複数箇所で利用している。
部分的な修正の方が悪影響を与える。提供
者と協議して書き換えるなら全部同時に実
施する。それまでは現状維持。
対応する
版 2015/5/8以降の版
逸脱手順
前回の検査時の数の変化の理由を確認し、
担当者および確認者が署名またはソースの
先頭に検査人の人名を入れる。
114

逸脱ルー
ル 69:ellipsis '...' shall not be used
逸脱理由提供側のヘッダファイルで規定しているため、
ルネサスと協議するまで留保。
対応する
版 2015/5/8以降の版
逸脱手順前回の検査時の数の変化の理由を確認し、
担当、確認の2名が署名。
115

逸脱ルー
ル
113:struct/union members shall be
named
逸脱理由利用しない値に名前を付けると間違えて使う
といけない。
対応する
版 2015/5/23以降の版
逸脱手順
前回の検査時の数の変化の理由を確認し、
担当者および確認者が署名またはソースの
先頭に検査人の人名を入れる。
116
2015年5月23日、担当:小川清、確認:X、文書番号gifu2015004

逸脱ルー
ル
Rule 2.2 (required):2004, Source code
shall only use /* … */ style comments.
逸脱箇所 2014, チェッカで検査し、逸脱一覧を添付。
逸脱理由
/* */コメントの方が間違いを誘引しやすくい。
RTL設計スタイルガイドも//推奨。MISRAのメ
ンバ組織でも組織逸脱を決めている。
対応する
版 2015/5/23以降の版
逸脱手順新たに記述、変更する部分のみ//を用いる。
組織の作業標準文書番号gifu201505に規定。
117

わかったこと
 わからなかったこと
 よかったこと
 これからやるとよいこと

前提
l  動的なメモリ利用は検証が困難
l メモリ確保の時間は可変
l メモリ確保できるかどうかは場合による
l メモリ解放がうまくいかずに、メモリ漏れ（leak)
l  ポインタ操作の範囲確認が大変
l 誤って命令、データを書き換え
l  CPU間のプログラムの移植の際に問題が発生
l 16bit, 32bit
l unsigned, singed
l 未規定、未定義，処理系定義

組み込みシステム
l  ハードウェアに近いところはＣ言語利用が多い
l アセンブラも混在する場合あり
l C++はじめ他の言語の利用の場合もある
l リアルタイム性が重要でない場合はJAVAなど
l  マイコン固有の機能の利用
l マイコン製造元が同時にC言語を出荷
l Cコンパイラ自体、C言語で記述
l Cの標準は特定のCPUを前提
l  16bit, 32bit
l 安全性（信頼性）, 可搬性（移植性）

MISRA(Motor Industry Softwre Reliability
Association)
l  MIRA(欧州の自動車関連団体:Motor Industry Research
Association)
l  Development guideline for vehicle based software（ISO TR 15497:)
自動車用ソフトウェアの開発ガイドライン(自動車技術会
TP-01001)
l  Guidelines for the use of the C language in vehicle based
software(MISRA C:1998)
自動車用C言語利用のガイドライン（自動車技術会TP-01002)
l  C90対応
l  解説書はSESSAME WG3
l  MISRA C:2004(C90対応）

MISRA C
l  C言語規格のPortabilityに対する疑問から、SaferCというより
安全なC言語の書き方の提案があった
l  自動車業界の要請により自動車業界のコーディングルール
として1998年に発行。HIS（ドイツの自動車業界団体）が
Automotive SPICE(ISO/IEC 15504), ISO OSEK, ISO CANな
どとともに採用
l  日本からの意見を含めて第二版を２００４年に発行
l  C99に対応した第三版を2012年に発行
(c)kaizen@wh.commufa.jp, @kaizen_nagoya組込み研修
2018/05/19

組込み開発者におくるMISRA C
組込みプログラミングの高信頼化ガイド
l  MISRA C 研究会(SESSAME WG3),
日本規格協会, 2004
l  C言語で書いたソフトウェアを他の
CPUに移植する際に問題となる事項
を洗い出し
l  C言語の規定のあいまいな事項を排
除して、不具合を減らす
l  参考文献
l  Safer C
l  C言語の落とし穴

MISRA C:1998 の概要
l  127項目の具体的なプログラミングルールと品質サブシステ
ムの解説
l  静的テストが可能なもの中心
l  93の必要と34の推奨
l  規格(C90)を基準として利用

MISRA C:1998の特徴
l  MISRA Cの合致は製品ごと
l  コードの書き方だけでなく、検証方法を要求（合致マトリック
ス）
l  守らない方がよい規則は逸脱の手続き
l  静的検査ツールによる検出を重視
l  静的なプログラムを推奨
l  メモリの動的確保はしない
l  ポインタの演算はしない

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

MISRA Cの利用方法
l  テスト仕様書の一部
l  品質指標を明確化
l  グローバルに対応
l  言語教育に利用
l  規則の取捨選択
l  Standing Deviation
l  静的検査ツールの利用

規則の分類（カテゴリ）
l  環境
l  文字セット
l  コメント
l  識別子
l  型
l  定数
l  宣言と定義
l  初期化
l  演算子
l  変換
l  式
l  制御フロー
l  関数
l  前処理指令
l  ポインタと配列
l  構造体と共用体
l  標準ライブラリ

課題の段階的詳細化
l  安全なシステムを構築するために、何ができるか。
l  ハードウェアとソフトウェアの責任境界の明確化〔対応）
l  大規模化するソフトウェアで、何が必要か。
l  共通の規則（一部対応）
l  高級アセンブラとしてCPUに依存した処理が書けるC言語には
何が必要か。
l  依存した部分の文書化（対応）
l  C言語の教育に必要なことは何か。
l  動くプログラムで教育（応用）
l  C言語の試験に必要なことは何か。
l  試験をしてからプログラム||試験のためのプログラムから出発（応用）

ハードウェアとソフトウェアの
責任境界の明確化
l  C言語のPortabilityにハードウェアとの責任境界が見える
l  CPUごとの試験
l  Cコンパイラの試験
l  OSの試験

プログラムの安全性
l  コンパイラ、チェッカ（静的解析ツール）で検査可能か
l  ルールを守らない方が安全な場合は逸脱の手続きを取る
l  警告が多いと見逃しがでるため、チェッカが逸脱の手続きと連
動しているとよい
l  警告のノイズ
l  真の警告ではない
l  チェッカの不具合
l  逸脱した方が品質が高い
l  １つの事象に複数の警告がでる（一番優先順位の高いものだけでよいか
も）
l  ハードウェアと関係した試験とソフトウェアだけでできる試験を
分ける

共通の規則（一部対応）
l  機能安全
l  ISO 26262
l  作業標準
l  ISO TR 15497（MISRA SA)
l  スタイルガイド
l  アプリケーションごと
l  プログラミング言語ごと
l  命名規則
l  OSごと
l  アプリケーションごと
l  プログラミング言語ごと
l  言語に依存したコーディングルール
l  MISRA C

依存した部分の文書化
l  MISRA Cの逸脱の手続き
l  規則を守るのがよいとは限らない
l  処理速度の低下
l  コードの移植性の低下
l  規則の逸脱する方がよい場合がある
l  形式的な規則の適用の危険性
l  例：
l  アセンブラのソースコード
l  複数箇所からの戻り

OSとコンパイラ
l  C言語がＯＳの存在を想定している場合と、ＯＳがない場合の
２つの標準
l  Host環境
l  Freestanding環境
l  ＯＳの存在を想定している場合には、ＯＳの規定が優先
l  文字コード、改行、エスケープシーケンス
l  クロス開発の場合には、開発用ＯＳと対象ＯＳの違いに留意
l  コンパイラによる動作の違い

試験をしてからプログラム
試験のためのプログラムから出発
l  最初は試験プログラムを書く
l  CPUの試験、Cコンパイラの試験、OSの試験、ライブラリの試
験から始める
l  試験プログラムを書くことにより、試験可能なプログラムが書
けるようになるかも
l  可搬性のあるプログラムを書けると再利用可能性が高くなる
かも

MISRA C
l  環境
1 (必須)全てのコードは ISO 9899 C
標準を満たしていなければなら
ず, 拡張機能は許されない。
3 (推奨)Cから呼び出されるアセン
ブリ言語の関数は, インラインア
センブリ言語のみが含まれてい
るCの関数として表現されなけれ
ばならず, インラインアセンブリ言
語は一般のCコード内に組み込
まれてはならない.
  5 (必須)ISO C標準で使用されてい
る文字や拡張表記のみ使用可能で
ある.
  8 (必須)マルチバイト文字や拡張文
字列リテラルは使用してはならない.
l  コメント
9 (必須)コメントは入れ子であってはな
らない.
10 (推奨)コード部は‘コメントアウト’して
はならない.
l  関数
82 (推奨)関数は1つの出口しか持って
はならない.

MISRA C対応の事前準備
l  処理系定義(ImplemantationDefinition)を確かめる
l  コンパイラ、OSを試験する
l  有効なルールか、現実ありそうなことかを確かめる
l  コンパイラによる違い。ＯＳの違い。
l  ルール間の矛盾がないかを確かめる
l  ルール１を守ると、自動的に守れるルール
l  ルール１を逸脱しているルール
l  ルール（Cの規格の規定）間の優先順位
l  MISRA Cの教材
l  動く事例
l  OS、コンパイラのソースをチェック記録
l  合致マトリックスの作成
l  逸脱の手続きの作成

例題
l  定義文書の例題はコンパイルできるとは限らない。
【例】
UI_8 var1 = '377'; /* OK: 8進拡張表記377は10進の255 */
UI_8 var2 = ‘0’; /* OK: 8進拡張表記0 (ナル文字に対応) */
UI_8 var3 = 'xFF'; /* OK: 16進拡張表記xffは10進の255 */
UI_8 var4=‘$’; /* NG:$は対応規格の未定義文字。未定義の動作 */
UI_8 var5=‘@’; /* NG:@は対応規格の未定義さ文字。未定義の動作 */
UI_8 var6=‘C’; /* NG: Cは未定義の拡張表記。未定義の動作 */

例題実行方法
  １：Windows/Linux上のコンパイラでのシュミレーション
l  stdio.hを利用
l  printf関数
l  main 関数
l  処理結果と処理経過を表示
l  利用したコンパイラ
l  Microsoft VisualStudio 6.0
l  (Cygwin/Linux) GCC 3.1.x/GCC 3.4.X
２：M32C,TOPPERS/jsp
l  タスクmonitorタスクを利用
l  Printf相当の関数あり
l  コンパイラ:ルネサス製N308
l  MISRA Cチェッカあり

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での動
作。*/
#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 date
  Rule: Rule #, rule(Japanese and English)
  Body:
  #inclue <misrac.h>
  …
  Result: Visual Studio　(microsoft),
  GCC,
  N308(Renesas Technology)
  Footer: update log

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

Rule.5
u  * rule 5: ISO C標準で使用している文字や拡張表記のみ使用
可能である.
u  * 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は定義されていない拡張表記 */
l  Ｃ標準で使用していない文字を認識。
l  OSで規定すべきこと->OSごとにStanding Deviationを規定するとよい。

Rule.8
l  Visual Studio では、「適合していないﾜｲﾄﾞ文字列を連結していま
す。」と出たが、gcc(cygwin)では、出なかった。
WC_T wct_ary[] = "abc" L"ABC"; /* NG: 潜在的問題(5)(補足参照) */
処理系により、警告、エラーが出る出ないの違いがある。
現場でチェッカを複数用意できない場合は、他のコンパイラにかけてみるのも手。

対応ツール
l  QAC
l  LDRAツールスイート
l  PG Relief C/C++
l  PolySpace Verifiler
l  C++TEST
l  Review C
l  SQMlint

MISRA C1998 まとめ
l  安全なシステムを構築するための、試験を前提としたコー
ディング規則
l  大規模化するソフトウェアで、命名規則と直交できるコーディ
ング規則
l  CPUに依存した処理の切り分け
l  C言語の教育にはOS、C言語のソースコードのコンパイルを
含む、現実の問題との対応
l  開発の最初から試験を行う

MISRA C1998 課題
l  MISRA C 2004
l  C99未対応
l  C99の不要な規定の除外または改定要求
l  OSの有無、種類によるstanding deviation
l  16bit, 32bitの固有の問題の識別(8bit, 64bit)
l  安全性の程度による適用

MISRA C(2004)ガイド
l  SESSAME WG3（MISRA C研究会）
l  IEC61508/ISO26262に基づくサブセット、ガイ
ドラインとして利用
l  1998年版に対する日本(MISRA C研究会）か
らの意見採用
l  ルールの厳密化
l  1998: (推奨)コード部は‘コメントアウト’し
てはならない.
l  2004:コメントの中で/*を書いてはいけな
い
l  ルール数の増加
l  厳密にしたため、あいまいなルールが詳
細なルールになる
l  不要なルールの削除
多言語のコメントの使用禁止
©MISRA C研究会

MISRA C：品質の視点
l  品質確認の文書化
l  規則としての文書化
l  3.1 処理系定義の動作はすべて文書化
l  3.2 文字集合及び円コーディング
l  3.3 整数除算の実装
l  3.4 #pragma命令
l  3.5 ビットフィールド
l  3.6 ライブラリ
l  逸脱の手続きとしての文書化
l  品質確保の技法例：
l  9.1すべての自動変数は用いる前に値を代入しなければならない。
l  14.1 到達しないコード
l  21.1 実行時の誤り

規則9.1 変数の初期値
l  すべての自動変数は
用いる前に値を代入し
なければならない。
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到達しないコード
l  到達しないコードがあってはなら
ない。
l  エラー検出のためのコードを埋
める場合には、逸脱の手続きを
取る。
l  逸脱がある程度あるものが品質が
高い可能性がある。
l  工業標準利用時の経験則（ベスト
プラクティス）
int_32t s32_inc(int32_t i){
i++;
return i;
print_error(UREAC)；
}
©MISRA C研
究会

C99未対応(1998/2004年版）
l  MISRA C:1998，2004とも//コメントを認めていない
l  コメントの便利さと危険性
l  C99未対応の理由
l  C99対応コンパイラが少ない
l  C99に詳細な規定が多い

主要参考文献
u The Motor Industry Software Reliability Association(1994):Development
Guidelines for Vehicle Base Software,ISBN 0952415607
u The Motor Industry Software Reliability Association(1998):Guidelines for
THE USE Of The language IN Vehicle Based Software ISBN 0952415690
u Guidelines for the use of the C language in critical systems, 2013, ISBN
9781906400-11-8 PDF
u JSAE(2002):JASO/TP-01001 自動車用ソフトウェアの開発ガイドライン,社
団法人自動車技術会
u JSAE(2002):JASO/TP-01002 自動車用Ｃ言語利用のガイドライン、社団法
人自動車技術会
u B.W.カーニハン,D.M.リッチー著,石田晴久(訳:1989)プログラミング言語Ｃ、
共立出版
u Ａ.コーニグ著.中村明(訳:2004）Cプログラミングの落とし穴,新紀元社
u アラン・R. フューアー著, 田中和明・手塚忠則 (訳:2000) The C
PuzzleBook,カットシステム

履歴
l 2.0 2004年7月CEST 自動車業界の C コーディング標準 MISRA C について
l 2.1 2004年9月電気関係学会東海支部
l 2.2 2005年3月日本科学技術連盟24回. 株ヴィッツ服部博行氏
l 3.0 2007年6月組込み研修
l 3.1 2007年9月電気関係学会東海支部で発表(項目数評価：ETSS利用効果測定)
l 3.2 2007年11月組み込みLinux研修
l 4.0 2008年企業向け研修
l 4.1 2009年SPIN研修
l 4.2 2009年MISRA C++研修
l 4.3 2009年組込み研修
l 4.4 2009年情報処理学会,MISRA C1998,MISRA C2004のC90,C99との検討,吉川直邦氏
l 5.0 2011年企業向け研修
l 6.0 2013年 OSC Nagoya2013
l 6.2 2014年2月CEST, MISRA=C:2012で楽しいCプログラミング
l 7.0 2015年2月セキュリティ・ESCR対応
l 7.1 2015年3月ソフトウェア科学会PPL2015
l 7.2 2015年5月 OSC Nagoya 2015

謝辞
  SESSAMEプロジェクト(MISRA C研究会）
  TOPPERSプロジェクト
  組込中核人材プロジェクト
  東陽テクニカ
  日本規格協会
  ISO/IEC JTC1 SC22 WG14
  自動車技術会
  トヨタ自動車
  株式会社ヴィッツ、株式会社セブンワイズ、株式会社サン
テック、有限会社ITプランニング、株式会社サニー技研
  株式会社ルネサステクノロジー、株式会社Spancion
  OSC事務局

参考文献
C言語のポータビリティとリーダビリティ,小川清,工業技術連絡会議電子連合部会コンピュータ
応用分科会ミニコン研究会,1987年10月
C言語の移植性とC++,小川清、小嶋久,電気関係学会東海支部連合大会,1987年10月
C言語利用システムの構成について,小川清,全NECユーザ会研究発表会,1988年3月
OBJの試用経験,小川清,二木厚吉,ソフトウェア技術者協会シンポジウム,1992年6月
MISRA‐C:1998とMISRA‐C:2004のC90,C99との検討,坪井泰樹, 吉川直邦(大同工大), 小川清,
斉藤直希,情報処理学会, 2005.3
高信頼性コーディング標準MISRA Cとそのサンプルの組込みボードを使った確かめ方,小川
清,岐阜県　組込みハード＆ソフト研究会,2006年11月
MISRA C/C++ の教育方法の提案,鈴木若菜,足立和規,渡辺翔,伊藤光, 堀武司,斉藤直希,渡
部謹二,小川清,電気関係学会東海支部連合大会,2009年9月
The C Puzzle bookを用いたC言語教育の展開高橋信貴, 小那覇安淑, 井上陽介, 伊藤光, 斉
藤直希, 渡部謹二, 小川清, 堀武司,電気関係学会東海支部連合大会講演論文集,2009.9
ソフトウェアFMEA を体系的に実施する出発点としてのMISRA C,株ヴィッツ森川聡久,2014年1
月 WOCS2014,
ソフトウェアFMEA を体系的に実施する出発点としてのMISRA C株ヴィッツ中野泰伸, 2014年7
月安全工学シンポジウム
MISRA C：2004から2012への移行の課題,株ヴィッツ萩原勝,2015.1月 WOCS2015,

Who enjoy a coding standard?

More Related Content

More from Kiyoshi Ogawa (20)

Who enjoy a coding standard?