2012年10月の記事一覧
C
投稿日時 : 2012/10/31
小川 清
小川 清
Fail-Safe C: 安全性を保証する C 言語コンパイラ
http://www.logos.t.u-tokyo.ac.jp/ppl_ss08/images/0/09/20080909-PPLss2.pdf
Fail-Safe C: 安全性を保証する実用C言語コンパイラの開発
http://www.rcis.aist.go.jp/files/events/2009/0515-ja/RCIS2009_Oiwa.pdf
安全なシステム記述言語および高信頼 OS 記述言語
http://web.yl.is.s.u-tokyo.ac.jp/e-society/yone-esoc-main.pdf
Implementation of the memory-safe fullANSI-C compiler
Safe!
Visual Studio 2005 Safe C および C++ ライブラリでコードへの攻撃を撃退する
http://msdn.microsoft.com/ja-jp/magazine/ee216340.aspx#04
ISO/IEC TR24731
[ 2 ] Austin, T. M., Breach, S. E., andSohi, G. S.:E±cient Detection of All Pointer and Array Access
Errors, Programming Language Design andImple-
mentation, 1994, pp. 290{301.
0
関数プログラミングへの道 MISRA-Cを経由して
投稿日時 : 2012/10/22
小川 清
小川 清
TOPPERS開発者会議のハッカソンの最中です。
TOPPERSプロジェクトに限らず，
自動車関連の仕事をしているかどうかに限らず，
MISRA-Cの理解がなかなか広がっていない事態に直面しています。
Cプログラマが、関数プログラミングを押し進める上で，
MISRA-Cが役立つことを確認しようとしています。
MISRA-C:2004の規則ごとに、
それぞれの規則がどれくらい貢献しているかを採点してみました。（現在の主観）
1 C言語プログラマが前提
2 関数プログラミングができるようになる方向を加算する
3 関数プログラミングをどういう言語で書くかは未定
課題
型に厳しい言語で書く場合と、型を推論してくれる言語で書く場合に、
関数プログラミングで必要な事項がどれくらい違うかを明確にできていない。
背景
経験として、関数プログラミングは、原則アセンブラで記述していた。
call
ret
という機能のある機械語を持つCPU上で。
参考文献
TOPPERSプロジェクトに限らず，
自動車関連の仕事をしているかどうかに限らず，
MISRA-Cの理解がなかなか広がっていない事態に直面しています。
Cプログラマが、関数プログラミングを押し進める上で，
MISRA-Cが役立つことを確認しようとしています。
MISRA-C:2004の規則ごとに、
それぞれの規則がどれくらい貢献しているかを採点してみました。（現在の主観）
関数プログラミングそのもの 5
関数プログラミングに貢献する 4
関数プログラミングならそうでしょ 3
関数プログラミングでもそうでしょ 2
関数プログラミングならありえない 1
5は関数プログラミングの例，
4は規格のC言語を用いたプログラミングから関数プログラミングへ近づく道
3は関数プログラミングしていたらあたりまえのこと
2は関数プログラミングをしていても、そうしないといけないかも。
1は関数プログラミングする上で役に立たない。
ここでは型を人手で宣言する言語かどうかは不定です。
人手で型を定義するかどうかで傾向が違うかもしれません。
前提条件5は関数プログラミングの例，
4は規格のC言語を用いたプログラミングから関数プログラミングへ近づく道
3は関数プログラミングしていたらあたりまえのこと
2は関数プログラミングをしていても、そうしないといけないかも。
1は関数プログラミングする上で役に立たない。
ここでは型を人手で宣言する言語かどうかは不定です。
人手で型を定義するかどうかで傾向が違うかもしれません。
ルール 1.1. (必要) ISO 9899:1990, 3
ルール 1.2. (必要) 未定義・未規定動作,4
ルール 1.3. (必要) 複数のコンパイラや言語の使用,3
ルール 1.4. (必要) 外部識別子名,3
ルール 1.5. (推奨) 浮動小数点規格,3
2. 言語拡張
ルール 2.1. (必要) アセンブリ言語,2
ルール 2.2. (必要) コメント,2
ルール 2.3. (必要) コメント内の /*,3
ルール 2.4. (推奨) コメントアウト,2
3. 文書化
ルール3.1. (必要) 処理系定義の動作,3
ルール 3.2. (必要) 文字集合とエンコーディング,3
ルール 3.3. (推奨) 整数除算,4
ルール 3.4. (必要) #pragma 指令,2
ルール 3.5. (必要) ビットフィールド,2
ルール 3.6. (必要) ライブラリ,3
4. 文字集合
ルール 4.1. (必要) 拡張表記,2
ルール 4.2. (必要) 3 文字表記,2
5. 識別子
ルール 5.1. (必要) 31 文字を超える識別子,3
ルール 5.2. (必要) 識別子の隠蔽?
ルール 5.3. (必要)typedef 名?
ルール 5.4. (必要)タグ名?
ルール 5.5. (推奨) オブジェクト・関数識別子の再使用?
ルール 5.6. (推奨) ネームスペース?
ルール 5.7. (推奨) 識別子の再使用?
識別子のところで悩み中。
各項目に覚えを書いています。
例：5.1, 31文字という値がいいかどうかは検討を要する。値を決めることは価値がある。
識別子のところで悩み中。
各項目に覚えを書いています。
例：5.1, 31文字という値がいいかどうかは検討を要する。値を決めることは価値がある。
1 C言語プログラマが前提
2 関数プログラミングができるようになる方向を加算する
3 関数プログラミングをどういう言語で書くかは未定
課題
型に厳しい言語で書く場合と、型を推論してくれる言語で書く場合に、
関数プログラミングで必要な事項がどれくらい違うかを明確にできていない。
背景
経験として、関数プログラミングは、原則アセンブラで記述していた。
call
ret
という機能のある機械語を持つCPU上で。
参考文献
0