Who like C++ coding standard

コーディング標準は誰のため？
発表はCおよびC++
質問他言語可
ver 0.5
技術士（情報工学）・工学博士小川清
名古屋市工業研究所
2018/06/05 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

今日の伝言
C++の雛形(template)を使いこなそう
OSをC++で書くために
五大言語は押さえとこう
C++の特徴五つ
コーディング標準は誰のため？
日本語よりも英語で話をした方がコンパイルで
きるプログラムが作れる。

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

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

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

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

重要五言語
Python:機械学習、道具の命令、
C:コンパイラ、OS
C#：CLI=.NET枠組(Windows)
JAVA:Java Virtual Machine
C++:Cの代替, boost, LLVM

CLI
CLI:Common Language Infrastracture
JVM:Java Virtual Machine
LLVM:(low level virtual machine)
LLVM
JVM

C++の処理系
Visual C++: C#と共通基盤
g++: クロスコンパイラが豊富
clang++:コンパイラを記述

Effective Modern C++
template
auto
decltype
constexpr
無名関数(lambda function)

template
C with classからC++へ
実行時の動的管理から翻訳時の静的管理へ
汎用化
関数template
難しいことを覚えるより簡単な記述を編み出そう
ing

auto
型検査への逆行ではないか？
汎用算譜への手順

decltype
declared type deduction

constexpr
constant expressions.

無名関数(lambda function)
名前をつけないため名前衝突を考慮しなくて良い
関数の引数に渡せる
#include <iostream>
#include <algorithm>
#include <vector>
int main() {
const std::vector<int> ary { 1, 5, -1, 3, 0, -2, };
std::cout << "Count of negative numbers = " <<
std::count_if(ary.begin(), ary.end(), [](auto x)
{ return x < 0; }) << std::endl;
return 0;
}

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

規則を守れ!

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

何のために？

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

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

可読性上がった？

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

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

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

Namespaceの例：規格のコード
断片コンパイルしているときにコ
ンパイルエラーを取るためだけ
に使っている方法。
品質はあげない。
可読性あげない。

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

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

/**/コメントと//コメント
STARC RTL設計スタイルガイド verilog HDL
編では//コメントを推奨
MISRA C 1998, 2004では//コメントを禁止
どっちが品質に悪い影響を与えやすいかは
自明？
Rule A2-8-4 (required, implementation,
automated) C-style comments shall not be
used.

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

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

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

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

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

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

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

じゃどうすればいいの

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

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

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

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

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

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

理想論？

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

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

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

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

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

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

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

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

運用次第

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

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

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

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

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

今困っていること
コンパイルエラーを修正する方法
リンクエラーを取る方法
実行時エラーを取る方法
意味のある出力を出す方法
新たなコンパイルエラーが発生する

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行続く

お配りした題材
課題１次のコンパイルエラーをなくしてください。
C++N4741(12)6.4.1 Unqualified name lookup
[basic.lookup.unqual]p35-3.cpp"
課題2 次のコンパイルエラーをなくしてください。
"C++N4741(50)8.5.1.9 Static cast [expr.static.cast]p105-
2.cpp
課題3 次のリンクエラーをなくしてください
C++N4741(18)6.4.5 Class member access
[basic.lookup.classref]p45.cpp
課題4 次の実行時エラーをなくしてください
C++N4741(47)8.5.1.2 Function call [expr.call]p100a.cpp

本日の想定する道具(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 答合せ
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.co
m/ ctraps.pdf The C Puzzle Bookが参
考文献。
1995
Bell Laboratory

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

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

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

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

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

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

動くプログラムで教育
 The C Puzzle Book
 危険なプログラムの確かめ
 Cプログラミングの落とし穴
 MISRAに対応規則記述
 Cコンパイラ自体のコンパイル
 OSのソースのコンパイル
 TOPPERSのMISRA C対応
 国際規格・コーディン
グ標準の例(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/06/05 (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;
}
問題６Ｃプ
ログラミング
の落とし穴©
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に対応すると関数プログラミングに近づく
副作用が処理系定義などのため、副作用を避ける

Ｃ言語の規格
 K&R(de facto)C言語作者の文書
 アメリカ規格(de jure)
 ANSI X. 1989(C89):1999版からISO/IECと同時進行
 国際規格:フリースタングィング環境(main無可)，ホス
ト環境（main引数有）
 ISO/IEC 9899:1990(C90=ANSI C89)
 AMD 1995
 ISO/IEC 9899:1999(C99)
 ISO/IEC 9899:2011(C2011)
 国内規格
 JIS X 3010:1993(C90), JIS X 3010：2004(C99)
 最新版は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.o
rg/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: 天才の書いたプログラムを、凡人が間違ったプログラムにしてしまう
ことがある。凡人にも理解出来るコードが書けるのも天才の技。

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

未定義(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 the2018/06/05 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

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

目的
 異なるCPUでコンパイルしたときに同じ振舞をする
 安全なシステムを構築するための試験，証明。
 大規模化するソフトウェアの構造化。
 CPUに依存した処理が書ける（高級アセンブラ）。
 C言語教育に必要なこと。
 Cコンパイラを理解する（改良できる）：C言語で記述
 OSを理解する（改良できる）：C言語で記述
 ネットワークを理解する（改良できる）：C言語で記述
 C言語試験、証明
 空間（集合）の制限：MISRA C
 時間の検証：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以降の版
逸脱手順
前回の検査時の数の変化の理由を確認し、担
当者および確認者が署名またはソースの先頭
に検査人の人名を入れる。
126
2015年5月23日、担当:小川清、確認：X、文書番号
gifu2015001

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

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

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

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

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

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

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

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対応）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例題
 定義文書の例題はコンパイルできるとは限らない。
【例】
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上のコンパイラでのシュミレーション
 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チェッカあり

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
 * 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を規定するとよい。

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

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

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

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

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

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

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

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

主要参考文献
 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) The C
PuzzleBook,カットシステム

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

近日開催予定行事
名古屋市熱田区六番三丁目四番４１号で開催
ホップ、ステップ、HAZOP 2018/06/08（金）午前9時、
午前11時二度開催予定、無料
名古屋のIoTは名古屋のOSで 2018/06/21（木）無
料、定員10人。ただしRaspberry Pi持参の方定員越
え受付
ゼロから作るDeep Learning ❷ ―自然言語処理編
2018/07/19(木）午後無料
確率論及統計論輪講および Automotive SPICE,
実アセスメント毎月第二金曜日無料要事前連絡
SWEST 2018, 8/30（木）-8/31(金) 下呂水明館有料

ホップ、ステップ、HAZOP
2018/06/08（金）午前9時、午前11時二度開催予定、
名古屋市工業研究所電子技術総合センター５階コンピュータ研修室
定員10人。無料、筆記具をご持参ください。申込先：
@kaizen_nagoya
国際規格IEC 61882 HAZOPの短時間に三度繰り返す実習です。
今回は実例を元に分析予定。分析題材の持ち込み可。
午前９時からと午前１１時からの２回開催予定。それぞれ70分。２度出
ることも可能です。
資料（２部作）
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-
at-fukui-201712
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-
at-fukui-2017222018/06/05 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

名古屋のIoTは名古屋のOSで
2018/06/21（木）午後１時から５時半
無料、定員10人。 @kaizen_nagoyaに申込
Raspberry Pi持参の方は定員越えても受付
題材
温度センサによる測定、グラフ化
スマフォ、 Padから測定結果を閲覧、指令
Raspbianの入ったSDをお持ちいただけると、成果をお持ち帰りやすく
なります。
同じSDにTOPPERS/FMPの入れ方も説明します。

ゼロから作るDeep Learning
❷ 自然言語処理編読書会
2018/07/19(木）午後１時から午後５時
名古屋市工業研究所電子技術総合セン
ター５階コンピュータ研修室（六番町下車）
無料 @kaizen_nagoyaに申込
毎月１度（第三木曜を想定）
全員が読み手。１箇所担当

確率論及統計論輪講
Automotive SPICE実アセスメン
ト
毎月第二金曜日午前９時から午後5時１５分ま
午前中補習
定員40名、無料. 申込先：@kaizen_nagoya
参加要件：各種アセッサコース受講者
6月頃に名古屋市工業研究所でSPEAK-IPAアセッサ
コース（無料）開催予定。参加後、上記企画に参加可
NSOL SPEAK実アセスメントはNSOL SPEKアセッサーコース受講が
条件

SWEST
開催日程: 2018年8月30日(木)〜31日(金)
20周年を祝して8月29日(水)から特別企画開催
開催場所: 下呂温泉水明館 (岐阜県下呂市)
メインテーマ: future = SWEST(&you) + dream;
申込先等：http://swest.toppers.jp
参加費
参加区分 8月30日〜31日参加 8月29日参加追加費用
一般 29,000円 +16,000円
共催・協賛・後援団体会員(*)28,000円 +16,000円
学生 16,000円 +16,000円

Who like C++ coding standard

Recommended

Recommended

More Related Content

Similar to Who like C++ coding standard

Similar to Who like C++ coding standard (20)

More from Kiyoshi Ogawa

More from Kiyoshi Ogawa (20)

Who like C++ coding standard