study on safety and security ccoding standards

安全(safety)と安心(security)に関す
るC言語コーディング標準の取組

安全工学シンポジウム2015

小川清（技術士（情報工学）・工学博士・

　名古屋市工業研究所）

概要
•  0.
自己紹介

•  1.
背景

•  2.
C言語主要文献

•  3.
C言語標準

•  4.
C言語コーディング標準

•  5.
課題

•  6.
視点・処理系

•  6.
検討

•  7.
まとめ

自己紹介
•  VZエディタN5200移植

•  Minix手引書作成・配布

•  大学PC用通信エミュレータ移
植

•  連立微分方程式の解法
(Pade近似）

•  プログラムジェネレータの自
己生成

•  UNIX版FD作成

•  OBJシンタックスチェッカ作成

•  Mobile
IPを利用した経路選
択のためのパケット計測

•  公的試験研究機関、教育機
関での非常勤

JAXA/IPA
WOCSプログラム委員長

情報処理学会情報規格調査会
SC7WG10,20,24委員

NPO
SESSAME/MISRA-‐C研究会

NPO
TOPPERSプロジェクト理事

IPA/SEC連携委員

1.背景
•  計算機系安心(security)対策:社会的重大事象

•  多くの社会基盤の、計算機系

– OS(operaWng
system)、プログラミング言語、通信規
約の複雑な組み合わせ。

•  OS,
プログラミング言語処理系、通信系、応用ソ
フト用言語

– C言語で記述している場合が多い。

•  C言語標準とCPU

– 16bitから32bitに移行する段階で規定

– 16bitから32ビットで同じコードが動くことに焦点

1.1 危険な事象
•  暴走（止まらない）＝目的の処理をしない

•  メモリ破壊（設計外の値を書き込む）＝設計
外の振舞

– 設計外の処理を実行

•  設計外の処理を読み込み（動的処理）

– 値の漏洩

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

–  C言語標準WEBに審議文書を公開。

–  h[p://www.open-‐std.org/itc1/sc22/wg14/

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

•  C言語とOSの境界が必ずしも論理的な必然性が不明
確。

–  OSと通信規約との境界類似

•  C言語はプログラマが何でもできようにしてある

–  何をしたらいいかを絞り込むコーディング規約

•  Cの精神で専門性を持つことをうたってきた

–  セキュリティについて舵を切り替えている

2015/05/23

(c)kaizen@wh.commufa.jp,

@kaizen_nagoya

6

1.3
C言語設計者から見た構造
応用
通信規約
OS
C言語
CPU

1.4 応用ソフト設計者から見た構造
応用
応用ソフト用言語(C言語で生成）
通信規約
OS
C言語
CPU

1.5
Unix(Linux),C言語,CPUの構造
OS(Unix/Linux)
C言語
CPU

1.6
OS,C言語、CPU
CPU
CPU
CPU
C言
語
C言
語
CPU
OS(OSEK/AUTOSAR)
C言
語
CPU
CPU
CPU
OS
CPU

1.7
自動車用OS(OSEK/AUTOSAR)
•  自動車用通信規約CANは、物理層での衝突
防止機能により

•  エンジン・モータ制御は角速度制御で、発生
頻度の増減が激しい。

•  OSのタスク機能によるのではなくCPUの割り
込み機能を直接使う

•  診断(DIAG
)を通信により提供

２．C言語主要文献
•  黎明期(1972-‐1989)

– 2.1
K&R(bell研）

– 2.2
The
C
Puzzle
Book(bell研）

– 2.3
Cプログラミングの落とし穴(Bell研)

•  標準期(1989-‐2011)

– 2.4
Safer
C(安全系）

•  成熟期(2011-‐202X)

2015/05/23


@kaizen_nagoya

13

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 is ANSI-C)
• 1995 Safer C
• 1995 ISO/IEC 9899 Amd1
• 1998 MISRA C:1998
• 1999 ISO/IEC 9899
• 2004 MISRA C:2004
• 2008 CERT C 1st
• 2011 ISO/IEC 9899
• 2012 MISRA C:2012
• 2013 ISO/IEC TS 17961
2015/05/23


@kaizen_nagoya

14

2.1
K&R
•  アメリカ規格ANSI-‐C:1989ができ
るまで、1978年から10年間、C
言語教科書。

•  ANSI-‐C発行後、ANSI-‐C対応した
改訂。

•  K&Rの課題

–  最初の例が、main,
pring可変引
数変数

–  他のほとんどの関数は固定引数

–  可変引数が標準になるのはC++と
いう別言語
void
main(void){

pring(“Hello
World!”);

}

2.2　The
C
Puzzle
Book

•  ポインタなど、曲芸のような手の込
んだ、分かりにくいプログラム例を
示し、その出力を問う。

•  名古屋市工業研究所C言語研修で
演習問題として提示

•  全問正解(16bit,
32bitの違いを含
む）した人は0(#include
<me.h>

2.3　Cプログラミングの落とし穴
•  The
C
Puzzle
Bookより現実的な、
ありえる間違い易い書きの落とし
穴を示す。

•  MISRA
Cで参照

2.4
Safer
C

•  ISO/IEC
9899未定義、未規定、
処理系定義、文化圏固有で振舞
が異なることを指摘

•  上記記述を避けることにより、よ
り安全なコーディングが可能で
あることを提起。

3．C言語標準
•  C言語コンパイラ、OS(operaWng
system)を
記述するためのプログラミング言語

–  HOST環境：
OSあり

–  Free
Standing
環境:
C言語が想定しているOS
がない
•  異なるCPUにおいて類似の記述が利用でき
る：可搬性(portability)

–  CPUが違っていても似た機能を実現しやすい

–  未定義

–  未規定

–  処理系定義

–  文化圏定義

•  規格根拠文書(RaWonale)

–  Cの精神として「プログラマを信頼する」

大域

変数
スタック
関数A
ライブラ
リ関数
起動

関数
割込ベ
クタ
起動時
処理
大域

変数
スタック
関数A
ライブラ
リ関数
Main

関数
割込ベ
クタ
起動時
処理
freestanding
host

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

3.2
The
spirit
of
C,
AddiWonal
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
communiWes.
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
meeWng
was
that
there
should

be
no
invenWon,
without
excepWon.
Only
those
features
that
have
a
history

and
are
in
common
use
by
a
commercial
implementaWon
should
be

considered.
Also
there
must
be
care
to
standardize
these
features
in
a
way

that
would
make
the
Standard
and
the
commercial
implementaWon

compaWble.

14.
MigraWon
of
an
exisWng
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.

2015/05/23


@kaizen_nagoya

21

3.3 予備作業
•  コーディング標準のプログラム例を検討する前に、C
言語標準のプログラム例をコンパイルしてみるとよ
い。スパンシオンイノベンツの鹿野稔さんからのご助
言で取り組む

•  GCC,
LLVM(Clang),
Visual
Studio(C/C++)でコンパイル

–  25/100で現象確認

•  どこからもコンパイルエラーを検索できるよに
researchmap.jpで公開（月に１日以上休止しているこ
とが難点）

–  h[ps://researchmap.jp/jownvh0ye-‐1797580/#_1797580

•  8
5.2.4.2.2
CharacterisWcs
of
floaWng
types
<float.h>

NO
O

•  9
6.2.7
CompaWble
type
and
composite
type

XXX
X

•  13
6.4.5
String
literals
:Example

XO
O

•  19
6.5.2.2
FuncWon
calls:
Example

XXX
X

•  21
6.5.2.4
Posgix
increment
and
decrement
operators:note
98)
XO
XO

•  28
6.5.16.2
Compound
assignment:
Note
113)

XO
XO

•  33
6.7.3
Type
qualifiers
//Examples

XO
XO

•  36
6.7.6.1
Pointer
declarators
//
Example

LM
LM

•  39
6.7.7
Type
names

XXX
XX

•  42
6.8.3
Expression
and
null
statements
//
Examples
OO
OX

•  54
6.10.3.5
Scope
of
macro
definiWons
//Examples

XXX
X

•  65
7.17.2.1
The
ATOMIC_VAR_INIT
macro
//
Example
XO
XO

•  66
7.17.2.2
The
atomic_init
generic
funcWon
//
ExampleOO
O

•  67
7.17.3
Order
and
consistency
//NOTES
3

XO
XO

•  68
7.17.7.4
The
atomic_compare_exchange
generic
funcWons
//
Example
XO
XO

•  69
7.17.8
Atomic
flag
type
and
operaWons
//
Example
XO
XO

•  73
7.22.2.2
The
srand
funcWon
//
Example

OO
O,Gだと結果終わらない
•  85
F.9.1
Global
transformaWons
//
for
example

OO
GCC/LVM結果異なる
•  93
K.3.5.3.2
The
fscanf_s
funcWon
//
Examples

XXO

•  94
K.3.7.1.4
The
strncpy_s
funcWon

XXX

•  95
K.3.7.2.2
The
strncat_s
funcWon
//
Example

XXX

•  96
K.3.7.3.1
The
strtok_s
funcWon
//
Example

XXO

•  97
K.3.9.2.1.2
The
wcsncpy_s
funcWon
//
Example

XXX

•  98
K.3.9.2.2.2
The
wcsncat_s
funcWon
//
Example

XXX

•  99
K.3.9.2.3.1
The
wcstok_s
funcWon
//
Example

XXO

3.4
C2011断片翻訳考察
•  ライブラリの対応途上の処理系有

•  オープンソース処理系で差異有

4．C言語コーディング標準

•  黎明期(1972-‐1989)

•  標準期(1989-‐2011)

– 3.1
MISRA
C:1998(安全系）

– 3.2
MISRA
C:2004(安全系）

– 3.3
MISRA
C:2012(安全系）
•  成熟期(2011-‐202X)

– 3.4
CERT
C:2008

– 3.4
ISO/IEC
TS
17961:2013

– 3.5
CERT
C:2014

4.1
MISRA
C
•  Motor
Industry
Sovware
Reliability
AssociaWon,
by

MIRA

•  Safer
C,
Cプログラミングの落とし穴を参考

–  未定義、未規定、処理系定義を避ける

•  未検証のライブラリ関数を避ける

•  静的プログラミング

•  普及

–  自動車分野でより安全なコーディングを促進する業界標
準。

–  日本では東陽テクニカが先導して導入

–  翻訳は自動車技術会発行

–  解説はNPO法人SESSAEプロジェクト
MISRA
C研究会作成

4.2
CERT
C
•  安心(security)を実現するためのコーディング標準。

•  既存のコーディング標準参照。

–  CERT
C++
Secure
Coding
Standard

–  ISO/IEC
TR
24772:2013

•  主要な対応した道具一覧有

–  CLAIR
–  LDRA
tool
suite

–  PRQA
QA-‐C

–  CodeSonar

–  Compass/ROSE

•  参考文献（規則ごとに）

–  参考文献一覧：URLリンク切れ多し　＝＞更新を担当

4.3
ESCR

• 
MISRA
Cを参照

•  分野を特定しないコーディング標準例

– 英語版、日本語版有

4.4
ISO/IEC
TS
17961
• 
CERT
Cを始めとするコーディング標準の国際
的な仕様(speciﬁcaWon)の枠組み

•  MISRA
C参照

5．課題
•  5.1 関数(funcWon)

•  5.2
可搬性(portability)

•  5.3
安全(safety)

•  5.4
安心(security)

5.1 関数
•  C言語の関数は、入力を引数で受け取り、出
力を戻り値で返す。

•  大域変数は、入出力として任意に利用できる

•  自動車の適合では、大域変数においての特
定のメモリ領域に配置したい

引数
戻値
処理

出力
入力

メモリの利用構造（概念）
大域

変数
スタック
関数A
ライブラ
リ関数
Main

関数
割込ベ
クタ
起動時
処理
スタック
ライブラリ
関数(OS)
ライブラリ
関数(C言
語）
Main

関数
関数A
ライブラリ
関数

5.2 可搬性(portability)

•  未定義、未規定、処理系定義

•  16bit,
32bitによる違い、

•  host環境・freestanding環境による違い、

•  C90/C99などの準拠規格による違い

5.3
安全(safety)
•  動的領域確保

– 時間、処理結果を見積もりにくくする

•  確保時間

•  複雑な条件分岐

•  失敗

•  静的処理

– 起動時に利用するメモリを確定

– 実行時に、メモリの確保・返却をしない

– リカーシブコールのようなスタックオーバフローに
なる可能性のある処理を禁止

5.4
安心(security)
•  インタネットなどの膨大な、異なる型のデータ
を処理

•  安心なプログラム

– 動的処理を実施しても安心を確保するための方
法

•  CERT
C,
ISO/IEC
TS
17961で模索

6．視点・処理系
•  規格およびコーディング標準の意味を理解する
ため、すべてのプログラムの断片を、コンパイル
できるようにして振る舞いを確認するための視点
および処理系は次の通り。

•  6.1
16bit,
32bit

•  6.2
標準の版(C90/C99/C2011)

•  6.3
freestanding
/
host

•  6.4
処理系間の差異

•  6.5
CPU間の差異

6.1
16bit,
32bit
•  Int変数が16bit
CPU用だと16bit,32bit
CPU用
だと32bit

•  16bitのint変数でも乗算などの場合には、一
旦32bit保持する(整数拡張)

•  確認方法

– Open
Watcomが16bitと32bitの処理系を公開して
いる。16bit版は主にC90に対応で、32bit版は一
部C99への対応もしている。

6.2
標準の版(C90/C99/C2011)

•  GCC,
clang(LLVM)では、-‐std=c90,
c99で対応
する国際規格を選択することができる。

•  //コメントなどC99で規格になった機能は、ほ
とんどのC90コンパイラで対応している

– Verilog
HDL(Cプリプロセッサの機能を利用した
HDL言語)では、//コメント推奨

6.3
freestanding,
host

•  Host環境ではmain関数の記述が必須

–  Main関数の引数、戻り値はOSが規定

–  Host環境におけるOSとの境界はPOSIXで
規定

•  POSIXはUNIX,
Linux中心。MSはWindows

2000で対応

•  Feestanding環境ではmainでない関数
を規定可能
–  ライブラリ関数で対応は少しでもよい

•  GCC,
clang(LLVM)では、

-‐ﬀreestandingでfreestandingに対応。
大域

変数
スタック
関数A
ライブラ
リ関数
起動

関数
割込ベ
クタ
起動時
処理
大域

変数
スタック
関数A
ライブラ
リ関数
Main

関数
割込ベ
クタ
起動時
処理
freestanding
host

6.4処理系間の差異
•  上記4種類(LLVM,GCC,Open
Watcom16,32)に
加えて、Visual
Cを利用

•  Microsov
WindowsのOSでの利用が多く、
Express版は無償で利用。

6.5

CPU間の差異
•  POSIX
ISO/IEC
9945-‐1:1990

InformaWon
technology
-‐-‐
Portable

OperaWng
System
Interface
(POSIX)
-‐-‐
Part
1:
System

ApplicaWon
Program
Interface
(API)
[C
Language]

–  OSとC言語の境界規定

•  Linux:
ISO/IEC
23360-‐1:2006
Linux
Standard
Base
(LSB)
core

specificaWon
3.1
-‐-‐
Part
1:
Generic
specificaWon
CPUごとに規定

–  ISO/IEC
23360-‐2:2006

Part
2:
SpecificaWon
for
IA32
architecture

–  ISO/IEC
23360-‐3:2006

Part
3:
SpecificaWon
for
IA64
architecture

–  ISO/IEC
23360-‐4:2006

Part
4:
SpecificaWon
for
AMD64
architecture

–  ISO/IEC
23360-‐5:2006

Part
5:
SpecificaWon
for
PPC32
architecture

–  ISO/IEC
23360-‐6:2006

Part
6:
SpecificaWon
for
PPC64
architecture

–  ISO/IEC
23360-‐7:2006

Part
7:
SpecificaWon
for
S390
architecture

–  ISO/IEC
23360-‐8:2006

Part
8:
SpecificaWon
for
S390X
architecture

7．検討
•  7.1 コンパイルする前に

•  7.2
コンパイルするために

•  7.3
作業

– 7.3.1
ヘッダファイル

– 7.3.2
注釈(comment)

– 7.3.3
main関数

– 7.3.4
#ifdef

– 7.3.5 例のプログラムをOSのタスクに割当

7.1 コンパイルする前に
•  コードの断片を見ても、文法・意味の両面でわか
らない。

– 宣言がない：宣言の仕方で振舞いが違う

– 代入がない：値によって振舞いが違う

– 前・後処理がない：前後によって必要な処理が違う

– 出力がない：出力の仕方で必要な処理が違う

•  何をどう宣言したらコンパイルできるか分らない

•  何をしたいかがわからない

7.2
コンパイルするために
•  コードの断片が意味があるか

•  コンパイルできる状態にして意味があるか

•  実行して意味のある出力ができるか

7.3 作業
•  コード断片をコンパイルできるようにする

– 変数の宣言・必要なヘッダファイルのinclude

– 編集への初期値などの代入

•  できるだけ意味のある出力

– 処理結果を出力

– 条件分岐の結果が分かる出力

7.3.1
ヘッダファイル
•  共通定義を単一のヘッダファイルに定義

•  出力結果を確認

– The
C
Puzzle
bookのマクロ定義をC99に対応する
ように手を加えた。

ヘッダ
ファイ
ル

7.3.2 注釈
•  C90の/*

*/形式

•  C99以降の//形式

•  処理系の影響を受けないため、GCCの翻訳選択
で注釈の除去処理を行う。

–  Rubyのスクリプトで変換

–  GCCの注釈消去機能で注釈消去（ただし、注釈の記
述に関する規則には適用不可）

•  整合性の確認のためヘッダファイルは/*
*/形式
で記述した。

–  ヘッダファイルが仕様、Cソースが設計

7.3.3
main関数
•  freestanding環境のみで動作するものはvoid

main(void)形式、host環境での動作を想定し
ているものはint
main(void)形式とした。

7.3.4
#ifdef

•  アセンブラの表記方法など処理系固有の事
象に対応するため#ifdef前処理指令で対応し
た。

7.3.5 プログラム例をOSのタスクに割当
•  プログラム例をTOPPERS/sspのタスクに割付

•  対象CPUでの振舞の確認

– 自動車：開発のCPUと対象のCPUが異なる事有

•  プログラム例を次々試験

– タスクに割当で同時に複数の処理を確認

•  動的読み込み可能な仕様

– 順次タスクを読み込み主記憶の制限を受けない

– 関数に割当順次呼び出す方法でも可能

8．まとめ
•  C言語の黎明期、標準期、成熟期に時代を分割してC
言語の現状と将来像を示した

•  危険な事象は静的処理で限定可能

•  コーディング規約に従えば、可搬性が高く、安全・安心
なプログラムを書く出発点

•  C標準のコード断片を翻訳し現状の一旦を垣間見た

•  コーディング標準のコード断片を翻訳して確認

•  安心(security)のコーディング標準のISO/IECのTS発行
を機に、安全のコーディング標準との共存生を確認中

•  C言語ではmain関数の戻り値以外の入出力は副作用

8.1
課題
•  安心系・安全系のコーディング標準

–  相互の共存、参照関係（危険な事象の排除）

–  CPU,
C言語、OSの境界規定を見直し(POSIX,
LINUX)

•  32bitと64bitの可搬性

•  関数

–  環境との入出力を含めて関数の作用として定義する枠組
み(日本ソフトウェア科学会PPL2015で提言有）

–  関数の引数、戻り値として構造体を受け渡しでき、かつ値
はメモリの特定領域だけを利用して、適合・診断に利用で
きるようなCPU、言語処理系

•  自動車用のCPU,
C言語,
OSの境界規定の見直し

–  検証可能なCPU,
検証可能な言語、検証可能なOS

参考文献(1/2)
•  1.
ISO/IEC
9899:
2011,
ISO/IEC
JTC1/SC22/WG14

•  2.
Ratoionale
for
ISO/IEC
9899:1999,
SC22/WG14

•  3.The
C
programming
language,
K&R,
1978

•  4.
ANSI-‐X3.159:1989
C,
X3J11,1989

•  5.
ISO/IEC14882:2014
InformaWon
technology
Programming
languages
C+
+,
SC22/WG14

•  6.The
C
Puzzle
Book,
Alan
R.Feuer,
1982

•  7.C
プログラミングの落とし穴,
A
Konig,
1989

•  8.
MISRA
C,
h[p://www.misra.org.uk/forum/,
1989

•  9.
CERT
C,
h[ps://www.securecoding.cert.org/,2011

•  10.
ESCR
組込みソフトウェア開発向けコーディング作法ガイドC
言語版,

IPA/SEC,2006

参考文献(2/2)
•  11.
ISO/IEC
TS
17961:2013InformaWon
technology,Programming

languages,
their
environments
and
system
sovware
interfaces,
C

secure
coding
rules

•  12.
GCC,
h[ps://gcc.gnu.org,
1987

•  13.
Clang/LLVM,
h[p://llvm.org/,
2007

•  14.
Open
Watcom,
sourceforge.net
openwatcom,2003

•  15.
Visual
C,
h[ps://www.visualstudio.com
,1983

•  16.
MISRAC
as
funcWon
programming
and
a
subset
of
standard,小
川清,PPL2015,日本ソフトウェア科学会
•  17.
NPO法人SESSAMEプロジェクト/MISRA
C
研究会,

www.sessame.jp,
2000

•  18.
MISRA
C
愛好会,
h[p://researchmap.jp/kaizen/MISRA
C
愛好
会,
2012

•  19.
Code
Complete,
Steve
McConnell,
1993

謝辞
•  SESSAMEプロジェクト(MISRA-‐C研究会）

•  TOPPERSプロジェクト

•  組込中核人材プロジェクト

•  東陽テクニカ

•  日本規格協会

•  ISO/IEC
JTC1
SC22
WG14

•  自動車技術会

•  トヨタ自動車

•  株式会社ヴィッツ、株式会社セブンワイズ、株式会社サンテック

•  株式会社ルネサス、株式会社Spancion

•  OSC事務局

16/07/09


@kaizen_nagoya

55

6.7
履歴

l 1.0 1998年 SPA研究会　Cコーディング標準について
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
16/07/09
@kaizen_nagoya
56

study on safety and security ccoding standards

Recommended

Recommended

More Related Content

Similar to study on safety and security ccoding standards

Similar to study on safety and security ccoding standards (20)

More from Kiyoshi Ogawa

More from Kiyoshi Ogawa (20)

Recently uploaded

Recently uploaded (8)

study on safety and security ccoding standards