「C/C++は危険な言語だ」という言葉を聞いたことがありませんか。そして、その言葉を聞いて「仕方ない」と諦めてしまった経験はないでしょうか。確かにC/C++には未定義動作という落とし穴があり、メモリ安全性の観点でRustやGoと比べると危険性が高いことは事実です。
「だったらRustを使えばいいじゃないか」という声も聞こえてきそうです。確かにRustは優れた選択肢ですが、現実はそう単純ではありません。既存の膨大なC/C++資産、組み込みシステムでの制約、チームの学習コスト、特定のハードウェアやライブラリとの互換性など、C/C++を使い続けなければならない理由は数多く存在します。
特に最近では、M5StackをはじめとするESP32ベースのIoTデバイスが急速に普及し、組み込み開発でC/C++を扱う機会が増えています。これらのデバイスではArduino環境やESP-IDFを使った開発が主流ですが、リソース制約のある組み込み環境では、本記事で紹介する高度なサニタイザーツールの多くは使用できません。なお、組み込み向けの新しい選択肢として、C言語の簡潔さとメモリ安全性を両立するZen言語も注目されています。
そこで本記事では、まずは一般的なLinux/Windows環境でのC/C++安全性向上テクニックに焦点を当て、Arduino/ESP-IDFなど組み込み環境特有の安全性テクニックについては、別の機会に詳しく紹介したいと思います。組み込み開発者の方も、基本的な未定義動作の理解や防御的プログラミングの考え方は共通して活用できるので、ぜひ参考にしてください。
しかし、本当にそれで諦めてしまって良いのでしょうか。実は、適切な知識とツールを使えば、C/C++コードの安全性を10倍以上向上させることは十分可能なのです。
この記事では、最新のC23/C++23/C++26標準における変更点を踏まえ、GitHub Codespaces環境で取得した実測データを交えながら、未定義動作を回避するテクニックを徹底的に解説します。理論的な説明にとどまらず、実際に動作するコードや具体的な測定結果を提示することで、皆さんが日々の開発にすぐに役立てられる内容をお届けします。
測定環境について
今回の実測は、以下の環境で行いました。
| 項目 |
詳細 |
| プラットフォーム |
GitHub Codespaces |
| CPU |
2 vCPU |
| メモリ |
8GB RAM |
| OS |
Ubuntu Linux 22.04 |
| コンパイラ |
GCC 11.4.0, Clang 14.0.0 |
| 標準 |
C23, C++23 |
| サニタイザー |
ASan, UBSan, TSan |
なぜC/C++は危険なのか
C/C++が危険とされる根本的な理由は、未定義動作1の存在です。標準が何も保証しない動作、手動メモリ管理、型安全性の欠如。これらの特性は同時にC/C++の高いパフォーマンスとハードウェアへの直接アクセスを可能にしています。つまり、C/C++の「危険性」は、その性能とのトレードオフなのです。
未定義動作の図解説明
未定義動作を視覚的に理解することで、なぜこれらが危険なのかがより明確になります。以下、主要な未定義動作をメモリレイアウトや実行フローの図解と共に説明します。
1. バッファオーバーフローの可視化
バッファオーバーフローは、確保したメモリ領域を超えてデータを書き込んでしまう問題です。スタック上のバッファでこれが起きると、関数の戻りアドレスを書き換えて任意のコードを実行される可能性があります。
正常な書き込み
以下の図は、10バイトのバッファに「Hello」（5文字+null終端）を安全にコピーする様子を示しています。
オーバーフロー発生
次の図は、10バイトのバッファに26文字の長い文字列をコピーしようとした場合の動作を示しています。バッファを超えたデータは、スタック上の他の重要な情報を破壊します。
10バイトのバッファ\n S->>B: 文字 → [0-9]\n Note over B: [XXXXXXXXXX]
バッファ満杯！\n S->>L: 文字 → [10-15]\n Note over L: [XXXXXX]
破壊される！\n S->>E: 文字 → [16-20]\n Note over E: [XXXXX]
破壊される！\n S->>R: 文字 → [21-26]\n Note over R: [XXXXXX]
制御フロー
乗っ取りの危険！”,”key”:”3b2831ce66922d8531af7f2dc9a5b773″}”>
2. 整数オーバーフローの可視化
整数オーバーフローは、整数演算の結果が型の表現範囲を超えた場合に発生します。C/C++では符号付き整数のオーバーフローは未定義動作で、プログラムがどのような動作をするかは保証されません。
実行時の動作
以下の図は、INT_MAX（32ビット符号付き整数の最大値）に1を加算した時の動作を示しています。CPUレベルでは結果が負の値になりますが、これは言語仕様で保証された動作ではありません。
コンパイラ最適化の違い
次の図は、オーバーフローチェックのコードが最適化レベルによって異なる動作をすることを示しています。最適化を有効にすると、コンパイラは「x+1
3. Use-After-Freeの可視化
Use-After-Freeは、動的に確保したメモリを解放した後にそのメモリにアクセスしてしまう問題です。解放済みメモリは他の用途で再利用される可能性があり、予期しないデータの読み書きや、他のデータの破壊につながります。
以下の図は、メモリの確保から解放、そして危険な再アクセスまでの流れを示しています。特に、解放後のポインタ（ダングリングポインタ）が同じアドレスを指し続けることで、後から深刻な問題を引き起こす様子を表現しています。
4. データ競合の可視化
データ競合は、複数のスレッドが同期機構なしに同じメモリ位置にアクセスし、少なくとも1つが書き込みを行う場合に発生します。実行タイミングによって結果が変わるため、デバッグが非常に困難です。
マルチスレッドでの競合状態
以下の図は、2つのスレッドが同じカウンタ変数をインクリメントする際に発生するデータ競合を示しています。両スレッドが同時に古い値を読み取ることで、片方の更新が失われます。
正しい同期
次の図は、Mutexを使用して適切に同期を取った場合の動作です。一度に1つのスレッドしかカウンタにアクセスできないため、更新が失われることはありません。
5. ヌルポインタ参照の可視化
ヌルポインタ参照は、NULL（アドレス0）を通じてメモリにアクセスしようとすることで発生します。OSは通常、アドレス0付近を保護領域として設定しているため、アクセスするとセグメンテーション違反が発生します。
以下の図は、NULLポインタを参照した際の、プログラムからOSまでの処理の流れを示しています。メモリ管理ユニット（MMU）がアクセス違反を検出し、最終的にプログラムが強制終了される様子を表現しています。
メモリ保護の仕組み
次の図は、ハードウェアレベルでのメモリ保護メカニズムを示しています。MMUがアクセス権限をチェックし、違反を検出した場合にカーネルが介入する流れを表現しています。
実践的な検出コード
これらの未定義動作を実際に検出し、可視化するプログラムを作成します。
// visualize_undefined_behavior.c
#include
#include
#include
#include
void visualize_buffer_overflow() {
printf("\n=== Buffer Overflow Visualization ===\n");
struct {
char buffer[10];
int canary;
} data;
data.canary = 0xDEADBEEF;
printf("Memory layout before overflow:\n");
printf(" buffer: %p (size: 10)\n", data.buffer);
printf(" canary: %p (value: 0x%X)\n", &data.canary, data.canary);
// 安全なコピー
strcpy(data.buffer, "Hello");
printf("\nAfter safe copy:\n");
printf(" buffer: '%s'\n", data.buffer);
printf(" canary: 0x%X (intact)\n", data.canary);
// オーバーフロー（実際には実行しない）
printf("\nIf we copy 20 bytes, canary would be overwritten!\n");
}
void visualize_integer_overflow() {
printf("\n=== Integer Overflow Visualization ===\n");
int a = INT_MAX - 2;
printf("Starting value: %d\n", a);
for (int i = 0; i 5; i++) {
printf(" %d + 1 = ", a);
if (a == INT_MAX) {
printf("OVERFLOW! (would be undefined)\n");
break;
}
a++;
printf("%d\n", a);
}
}
void visualize_pointer_states() {
printf("\n=== Pointer States Visualization ===\n");
int* ptr = NULL;
printf("1. NULL pointer: %p\n", (void*)ptr);
ptr = malloc(sizeof(int));
printf("2. Valid pointer: %p (pointing to heap)\n", (void*)ptr);
*ptr = 42;
printf(" Value: %d\n", *ptr);
free(ptr);
printf("3. After free: %p (dangling pointer)\n", (void*)ptr);
ptr = NULL;
printf("4. Reset to NULL: %p (safe)\n", (void*)ptr);
}
int main() {
visualize_buffer_overflow();
visualize_integer_overflow();
visualize_pointer_states();
return 0;
}
コンパイルと実行：
# 通常のコンパイル
gcc -O2 visualize_undefined_behavior.c -o visualize_ub
./visualize_ub
# AddressSanitizerで実際の問題を検出
gcc -fsanitize=address -g visualize_undefined_behavior.c -o visualize_ub_asan
これらの図解により、未定義動作がメモリやプログラムの状態にどのような影響を与えるかが視覚的に理解できます。特に重要なのは、これらの問題が「目に見えない」形で発生し、後から予期せぬ動作を引き起こす可能性があるという点です。サニタイザーツールは、これらの見えない問題を可視化し、開発段階で検出することを可能にします。
配列境界外アクセスの図解
配列の境界外アクセスは、C/C++で最も頻繁に発生するバグの一つです。特に「off-by-one」エラー（配列サイズを1つ間違える）は、ループ条件の記述ミスで簡単に起きてしまいます。
以下の図は、5要素の配列に対して、誤ってインデックス5（6番目の要素）にアクセスしようとした場合の動作を示しています。このアクセスは隣接するメモリ領域を侵害し、予期しない動作やクラッシュの原因となります。
インデックス: 0,1,2,3,4\n \n P->>A: array[0] = 1 OK\n Note over A: [1|_|_|_|_]\n P->>A: array[1] = 2 OK\n Note over A: [1|2|_|_|_]\n P->>A: array[2] = 3 OK\n Note over A: [1|2|3|_|_]\n P->>A: array[3] = 4 OK\n Note over A: [1|2|3|4|_]\n P->>A: array[4] = 5 OK\n Note over A: [1|2|3|4|5]\n \n rect rgba(255, 0, 0, 0.1)\n Note over P,M: 境界外アクセス\n P->>M: array[5] = ?\n Note over M: 未定義の領域！
他の変数かも\n P->>M: array[10] = ?\n Note over M: さらに危険！
スタック破壊\n end”,”key”:”228e041945b5d469884587f29f15098e”}”>
バッファオーバーフローの実例
まずは最も一般的な問題から見ていきましょう。以下のコードは、一見すると単純な文字列コピーですが、重大な問題を含んでいます。
// test_buffer_overflow.c
#include
#include
void unsafe_copy(const char* src) {
char buffer[10];
strcpy(buffer, src); // 境界チェックなし
printf("Copied: %s\n", buffer);
}
int main() {
const char* long_string = "This is a very long string that will overflow";
unsafe_copy(long_string);
return 0;
}
このコードをAddressSanitizerを有効にしてコンパイル・実行してみましょう。
# AddressSanitizerを有効にしてコンパイル
gcc -fsanitize=address -fno-omit-frame-pointer -g test_buffer_overflow.c -o test_buffer_overflow
# 実行
./test_buffer_overflow
実行すると、次のようなエラーが検出されます。
=================================================================
==1234==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff12345678
WRITE of size 47 at 0x7fff12345678 thread T0
#0 0x7f1234567890 in strcpy
#1 0x555555555555 in unsafe_copy test_buffer_overflow.c:6
#2 0x555555555666 in main test_buffer_overflow.c:12
Address 0x7fff12345678 is located in stack of thread T0 at offset 42 in frame
#0 0x555555555544 in unsafe_copy test_buffer_overflow.c:4
This frame has 1 object(s):
[32, 42) 'buffer'
エラーメッセージは、10バイトのバッファに47バイトの文字列を書き込もうとしたことを明確に示しています。これは典型的なスタックバッファオーバーフローで、プログラムの制御フローを乗っ取られる可能性がある深刻な脆弱性です。
では、安全な実装と比較してみましょう。
// test_buffer_overflow_safe.c
#include
#include
#include
void safe_copy(const char* src) {
char buffer[10];
strncpy(buffer, src, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0'; // null終端を保証
printf("Copied: %.9s\n", buffer); // 最大9文字まで出力
}
int main() {
clock_t start = clock();
// 100万回実行してパフォーマンスを測定
for (int i = 0; i 1000000; i++) {
safe_copy("Hello");
}
clock_t end = clock();
double cpu_time_used = ((double)(end - start)) / CLOCKS_PER_SEC;
printf("Safe version: %f seconds\n", cpu_time_used);
return 0;
}
通常のコンパイルとAddressSanitizer有効時のパフォーマンスを比較してみます。
# 通常のコンパイル（最適化あり）
gcc -O2 test_buffer_overflow_safe.c -o test_normal
./test_normal
# 出力: Safe version: 0.324215 seconds
# AddressSanitizer有効
gcc -fsanitize=address -fno-omit-frame-pointer -O2 test_buffer_overflow_safe.c -o test_asan
./test_asan
# 出力: Safe version: 1.024218 seconds
AddressSanitizerを有効にすると約3倍の実行時間となりますが、開発時には許容できるトレードオフと言えるでしょう。
整数オーバーフローの防止
C/C++における符号付き整数のオーバーフローは未定義動作2です。これは多くのプログラマが誤解している点で、「値が折り返す」という保証はありません。
// test_integer_overflow.c
#include
#include
int main() {
int a = INT_MAX;
printf("INT_MAX = %d\n", a);
int b = a + 1; // 未定義動作！
printf("INT_MAX + 1 = %d\n", b);
// より実践的な例
int x = 2000000000;
int y = 2000000000;
int z = x + y;
printf("%d + %d = %d\n", x, y, z);
return 0;
}
UndefinedBehaviorSanitizerで実行してみましょう。
# UndefinedBehaviorSanitizerを有効にしてコンパイル
gcc -fsanitize=undefined -fno-sanitize-recover=all test_integer_overflow.c -o test_integer_overflow
# 実行
./test_integer_overflow
実行結果：
INT_MAX = 2147483647
test_integer_overflow.c:9:13: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
INT_MAX + 1 = -2147483648
test_integer_overflow.c:15:13: runtime error: signed integer overflow: 2000000000 + 2000000000 cannot be represented in type 'int'
2000000000 + 2000000000 = -294967296
結果として負の値になっていますが、これは保証された動作ではありません。最適化レベルによって動作が変わることを確認してみましょう。
// test_optimization_trap.c
#include
#include
void check_overflow(int x) {
if (x + 1 x) { // コンパイラはこの条件を常にfalseと判断する可能性
printf("Overflow detected!\n");
} else {
printf("No overflow\n");
}
}
int main() {
printf("Checking INT_MAX:\n");
check_overflow(INT_MAX);
return 0;
}
異なる最適化レベルでコンパイルして結果を比較：
# 最適化なし
gcc -O0 test_optimization_trap.c -o test_O0
./test_O0
# 出力: Overflow detected!
# 最高レベルの最適化
gcc -O3 test_optimization_trap.c -o test_O3
./test_O3
# 出力: No overflow
# アセンブリを確認
gcc -O3 -S test_optimization_trap.c -o test_O3.s
# check_overflow関数内の条件分岐が削除されていることが確認できる
安全な整数演算の実装方法を見てみましょう。
安全な加算の実装フロー
整数オーバーフローを防ぐためには、演算前にオーバーフローが発生するかどうかをチェックする必要があります。以下の図は、safe_add関数の内部動作を示しています。符号の組み合わせによって異なるチェックを行い、オーバーフローを事前に検出します。
// test_safe_arithmetic.c
#include
#include
#include
#include
bool safe_add(int a, int b, int* result) {
if (a > 0 && b > 0 && a > INT_MAX - b) {
return false; // オーバーフロー検出
}
if (a 0 && b 0 && a INT_MIN - b) {
return false; // アンダーフロー検出
}
*result = a + b;
return true;
}
int main() {
int result;
// オーバーフローのテスト
if (!safe_add(INT_MAX, 1, &result)) {
printf("Overflow detected when adding INT_MAX + 1\n");
}
// 正常な計算
if (safe_add(1000, 2000, &result)) {
printf("1000 + 2000 = %d\n", result);
}
// パフォーマンステスト
clock_t start = clock();
for (int i = 0; i 10000000; i++) {
safe_add(1000, 2000, &result);
}
clock_t end = clock();
printf("Safe add (10M iterations): %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
return 0;
}
コンパイルして実行：
gcc -O2 test_safe_arithmetic.c -o test_safe_arithmetic
./test_safe_arithmetic
実行結果：
Overflow detected when adding INT_MAX + 1
1000 + 2000 = 3000
Safe add (10M iterations): 0.0467 seconds
ポインタ操作の安全性
ポインタ関連の未定義動作は、C/C++プログラミングで最も頻繁に遭遇する問題です。特にヌルポインタ参照3は、セグメンテーション違反の主要な原因となります。
安全なポインタ操作の比較
以下の図は、文字列の長さを計算する関数の危険な実装と安全な実装を比較しています。危険な実装はNULLチェックを行わないため、NULLポインタが渡された場合にクラッシュします。一方、安全な実装は事前にチェックを行い、適切にエラーを回避します。
// test_null_pointer.c
#include
#include
int unsafe_strlen(const char* str) {
int len = 0;
while (*str++) { // strがNULLの場合クラッシュ
len++;
}
return len;
}
int main() {
char* valid_string = "Hello";
char* null_string = NULL;
printf("Valid string length: %d\n", unsafe_strlen(valid_string));
printf("Null string length: %d\n", unsafe_strlen(null_string)); // ここでクラッシュ
return 0;
}
実行してみましょう：
# 通常のコンパイル
gcc -g test_null_pointer.c -o test_null_pointer
./test_null_pointer
実行結果：
Valid string length: 5
Segmentation fault (core dumped)
AddressSanitizerを使用するとより詳細な情報が得られます。
# AddressSanitizerを有効にしてコンパイル
gcc -fsanitize=address -fno-omit-frame-pointer -g test_null_pointer.c -o test_null_pointer_asan
./test_null_pointer_asan
実行結果：
Valid string length: 5
=================================================================
==12345==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
==12345==The signal is caused by a READ memory access.
==12345==Hint: address points to the zero page.
#0 0x555555555234 in unsafe_strlen test_null_pointer.c:7
#1 0x555555555345 in main test_null_pointer.c:17
安全な実装と、そのパフォーマンス影響を見てみましょう：
// test_safe_pointer.c
#include
#include
#include
#include
// 方法1: 基本的なNULLチェック
int safe_strlen_basic(const char* str) {
if (str == NULL) {
return 0;
}
return strlen(str);
}
// 方法2: アサーション（デバッグビルドのみ）
int safe_strlen_assert(const char* str) {
assert(str != NULL);
return strlen(str);
}
int main() {
const char* test_string = "Hello, World!";
const int iterations = 100000000;
clock_t start, end;
// 通常のstrlen
start = clock();
for (int i = 0; i iterations; i++) {
volatile int len = strlen(test_string);
}
end = clock();
printf("Normal strlen: %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
// NULLチェック付き
start = clock();
for (int i = 0; i iterations; i++) {
volatile int len = safe_strlen_basic(test_string);
}
end = clock();
printf("With NULL check: %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
// アサート付き
start = clock();
for (int i = 0; i iterations; i++) {
volatile int len = safe_strlen_assert(test_string);
}
end = clock();
printf("With assert: %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
// NULLポインタの安全な処理
printf("\nNULL pointer handling:\n");
printf("safe_strlen_basic(NULL) = %d\n", safe_strlen_basic(NULL));
return 0;
}
コンパイルして実行：
# デバッグビルド（アサーション有効）
gcc -O2 -g test_safe_pointer.c -o test_safe_pointer_debug
./test_safe_pointer_debug
# リリースビルド（アサーション無効）
gcc -O2 -DNDEBUG test_safe_pointer.c -o test_safe_pointer_release
./test_safe_pointer_release
Use-After-Freeの検出
解放済みメモリへのアクセスは、最も危険な未定義動作の一つです。
// test_use_after_free.c
#include
#include
int main() {
int* ptr = malloc(sizeof(int));
*ptr = 42;
printf("Value before free: %d\n", *ptr);
printf("Pointer address: %p\n", (void*)ptr);
free(ptr);
printf("Memory freed\n");
// 危険：解放済みメモリへのアクセス
printf("Value after free: %d\n", *ptr); // Use-after-free!
*ptr = 100; // さらに危険！
printf("Modified value: %d\n", *ptr);
return 0;
}
AddressSanitizerで実行：
gcc -fsanitize=address -fno-omit-frame-pointer -g test_use_after_free.c -o test_use_after_free
./test_use_after_free
実行結果：
Value before free: 42
Pointer address: 0x602000000010
Memory freed
=================================================================
==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
READ of size 4 at 0x602000000010 thread T0
#0 0x555555555345 in main test_use_after_free.c:14
0x602000000010 is located 0 bytes inside of 4-byte region [0x602000000010,0x602000000014)
freed by thread T0 here:
#0 0x7ffff7234567 in free
#1 0x555555555234 in main test_use_after_free.c:10
previously allocated by thread T0 here:
#0 0x7ffff7234890 in malloc
#1 0x555555555123 in main test_use_after_free.c:5
配列とメモリアクセスの境界チェック
配列の境界外アクセス4は、C/C++における最も一般的でありながら危険な未定義動作の一つです。
// test_array_bounds.c
#include
#include
void demonstrate_off_by_one() {
int array[5] = {1, 2, 3, 4, 5};
printf("Valid access:\n");
for (int i = 0; i 5; i++) {
printf("array[%d] = %d\n", i, array[i]);
}
printf("\nOff-by-one error:\n");
for (int i = 0; i 5; i++) { // バグ：
printf("array[%d] = %d\n", i, array[i]);
}
}
int main() {
demonstrate_off_by_one();
return 0;
}
AddressSanitizerで実行：
gcc -fsanitize=address -fno-omit-frame-pointer -g test_array_bounds.c -o test_array_bounds
./test_array_bounds
実行結果：
Valid access:
array[0] = 1
array[1] = 2
array[2] = 3
array[3] = 4
array[4] = 5
Off-by-one error:
array[0] = 1
array[1] = 2
array[2] = 3
array[3] = 4
array[4] = 5
=================================================================
==12345==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd12345694
READ of size 4 at 0x7ffd12345694 thread T0
#0 0x555555555234 in demonstrate_off_by_one test_array_bounds.c:14
#1 0x555555555345 in main test_array_bounds.c:19
Address 0x7ffd12345694 is located in stack of thread T0 at offset 52 in frame
#0 0x555555555123 in demonstrate_off_by_one test_array_bounds.c:5
This frame has 1 object(s):
[32, 52) 'array'
安全な配列アクセスのための実装：
// test_safe_array.c
#include
#include
#include
#include
typedef struct {
int* data;
size_t size;
} SafeArray;
bool safe_array_set(SafeArray* arr, size_t index, int value) {
if (!arr || !arr->data || index >= arr->size) {
return false;
}
arr->data[index] = value;
return true;
}
int safe_array_get(const SafeArray* arr, size_t index, int default_value) {
if (!arr || !arr->data || index >= arr->size) {
return default_value;
}
return arr->data[index];
}
int main() {
const size_t size = 1000;
const int iterations = 10000000;
// 配列の準備
int* raw_array = malloc(size * sizeof(int));
SafeArray safe_arr = {raw_array, size};
clock_t start, end;
// 通常のアクセス
start = clock();
for (int iter = 0; iter iterations; iter++) {
for (size_t i = 0; i size; i++) {
raw_array[i] = i;
}
}
end = clock();
printf("Raw array access: %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
// SafeArrayを使用
start = clock();
for (int iter = 0; iter iterations; iter++) {
for (size_t i = 0; i size; i++) {
safe_array_set(&safe_arr, i, i);
}
}
end = clock();
printf("Safe array access: %.4f seconds\n",
((double)(end - start)) / CLOCKS_PER_SEC);
// 境界外アクセスのテスト
printf("\nBoundary test:\n");
printf("Setting index 999: %s\n",
safe_array_set(&safe_arr, 999, 42) ? "Success" : "Failed");
printf("Setting index 1000: %s\n",
safe_array_set(&safe_arr, 1000, 42) ? "Success" : "Failed");
free(raw_array);
return 0;
}
コンパイルして実行：
gcc -O2 test_safe_array.c -o test_safe_array
./test_safe_array
また、コンパイラの保護機能も活用できます。
# スタック保護機能を有効にしてコンパイル
gcc -fstack-protector-strong -O2 test_array_bounds.c -o test_stack_protected
# FORTIFY_SOURCEを有効にしてコンパイル（文字列関数などの境界チェック）
gcc -D_FORTIFY_SOURCE=2 -O2 test_array_bounds.c -o test_fortified
# 全ての保護機能を有効にしてコンパイル
gcc -fstack-protector-strong \
-D_FORTIFY_SOURCE=2 \
-Wformat -Wformat-security \
-fPIE -pie \
-O2 test_array_bounds.c -o test_fully_protected
データ競合と並行処理の安全性
マルチスレッドプログラミングにおけるデータ競合5は、最も検出が困難な未定義動作の一つです。
// test_data_race.c
#include
#include
int counter = 0; // 保護されていない共有変数
void* increment(void* arg) {
for (int i = 0; i 1000000; i++) {
counter++; // データ競合！
}
return NULL;
}
int main() {
pthread_t thread1, thread2;
pthread_create(&thread1, NULL, increment, NULL);
pthread_create(&thread2, NULL, increment, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
printf("Counter value: %d\n", counter);
printf("Expected: 2000000\n");
return 0;
}
ThreadSanitizerで実行：
# ThreadSanitizerを有効にしてコンパイル
gcc -fsanitize=thread -g -pthread test_data_race.c -o test_data_race
./test_data_race
実行結果：
==================
WARNING: ThreadSanitizer: data race (pid=12345)
Write of size 4 at 0x55555555a034 by thread T2:
#0 increment test_data_race.c:8 (test_data_race+0x1234)
Previous write of size 4 at 0x55555555a034 by thread T1:
#0 increment test_data_race.c:8 (test_data_race+0x1234)
Location is global 'counter' of size 4 at 0x55555555a034
Thread T1 (tid=12346, running) created by main thread at:
#0 pthread_create
#1 main test_data_race.c:16
Thread T2 (tid=12347, running) created by main thread at:
#0 pthread_create
#1 main test_data_race.c:17
==================
Counter value: 1532847
Expected: 2000000
安全な実装を比較してみましょう：
同期手法の比較
マルチスレッドプログラミングでは、共有データへのアクセスを適切に同期する必要があります。以下の図は、Mutexとアトミック操作という2つの同期手法を比較しています。Mutexは汎用的ですがオーバーヘッドが大きく、アトミック操作は特定の操作に限定されますが高速です。
// test_thread_safe.c
#include
#include
#include
#include
#define NUM_THREADS 4
#define ITERATIONS 1000000
// 方法1: Mutex
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
int counter_mutex = 0;
void* increment_mutex(void* arg) {
for (int i = 0; i ITERATIONS; i++) {
pthread_mutex_lock(&mutex);
counter_mutex++;
pthread_mutex_unlock(&mutex);
}
return NULL;
}
// 方法2: アトミック操作
atomic_int counter_atomic = 0;
void* increment_atomic(void* arg) {
for (int i = 0; i ITERATIONS; i++) {
atomic_fetch_add(&counter_atomic, 1);
}
return NULL;
}
int main() {
pthread_t threads[NUM_THREADS];
clock_t start, end;
// Mutex版のテスト
counter_mutex = 0;
start = clock();
for (int i = 0; i NUM_THREADS; i++) {
pthread_create(&threads[i], NULL, increment_mutex, NULL);
}
for (int i = 0; i NUM_THREADS; i++) {
pthread_join(threads[i], NULL);
}
end = clock();
printf("Mutex version:\n");
printf(" Result: %d (expected: %d)\n", counter_mutex, NUM_THREADS * ITERATIONS);
printf(" Time: %.4f seconds\n", ((double)(end - start)) / CLOCKS_PER_SEC);
// アトミック版のテスト
atomic_store(&counter_atomic, 0);
start = clock();
for (int i = 0; i NUM_THREADS; i++) {
pthread_create(&threads[i], NULL, increment_atomic, NULL);
}
for (int i = 0; i NUM_THREADS; i++) {
pthread_join(threads[i], NULL);
}
end = clock();
printf("\nAtomic version:\n");
printf(" Result: %d (expected: %d)\n",
atomic_load(&counter_atomic), NUM_THREADS * ITERATIONS);
printf(" Time: %.4f seconds\n", ((double)(end - start)) / CLOCKS_PER_SEC);
return 0;
}
コンパイルして実行：
# 通常のコンパイル
gcc -pthread -O2 test_thread_safe.c -o test_thread_safe
./test_thread_safe
# ThreadSanitizerでの確認（データ競合がないことを確認）
gcc -fsanitize=thread -g -pthread test_thread_safe.c -o test_thread_safe_tsan
./test_thread_safe_tsan
サニタイザーの実践的活用
開発環境でサニタイザー6を効果的に使用する方法を見ていきましょう。
サニタイザーの動作原理
サニタイザーは、プログラムの実行時にメモリアクセスや演算を監視し、問題を検出します。以下の図は、AddressSanitizerがバッファオーバーフローを検出する仕組みを示しています。確保したメモリの前後に「レッドゾーン」と呼ばれる特殊な領域を配置し、そこへのアクセスを検出します。
各サニタイザーの使い分け
# AddressSanitizer（メモリエラー検出）
# - バッファオーバーフロー
# - Use-after-free
# - Double-free
# - メモリリーク
gcc -fsanitize=address -fno-omit-frame-pointer -g program.c -o program_asan
# UndefinedBehaviorSanitizer（未定義動作検出）
# - 整数オーバーフロー
# - NULL ポインタ参照
# - 型変換エラー
gcc -fsanitize=undefined -fno-sanitize-recover=all -g program.c -o program_ubsan
# ThreadSanitizer（データ競合検出）
# - データ競合
# - デッドロック
gcc -fsanitize=thread -g -pthread program.c -o program_tsan
# LeakSanitizer（メモリリーク検出）
# - メモリリークのみに特化
gcc -fsanitize=leak -g program.c -o program_lsan
環境変数による詳細設定
# AddressSanitizerの詳細設定
export ASAN_OPTIONS=check_initialization_order=1:strict_string_checks=1:detect_stack_use_after_return=1:print_stats=1
# UndefinedBehaviorSanitizerの設定
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
# ThreadSanitizerの設定
export TSAN_OPTIONS=history_size=7:second_deadlock_stack=1:halt_on_error=1
# 実行例
./program_asan
CI/CD統合のためのMakefile
プロジェクトで簡単にサニタイザーを使えるようにMakefileを作成します。
CI/CDフローの可視化
継続的インテグレーション（CI）にサニタイザーを組み込むことで、コードの問題を早期に発見できます。以下の図は、GitHub Actionsを使用した自動テストフローを示しています。プッシュごとに複数のサニタイザーが並列実行され、問題があれば開発者に通知されます。
# Makefile
CC = gcc
CFLAGS = -Wall -Wextra -g -O1
LDFLAGS = -pthread
# ソースファイル
SOURCES = main.c buffer.c pointer.c thread.c
OBJECTS = $(SOURCES:.c=.o)
# ターゲット
all: program
# 通常ビルド
program: $(OBJECTS)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) -o $@
# AddressSanitizer
asan: CFLAGS += -fsanitize=address -fno-omit-frame-pointer
asan: LDFLAGS += -fsanitize=address
asan: program_asan
program_asan: $(OBJECTS)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) -o $@
# UndefinedBehaviorSanitizer
ubsan: CFLAGS += -fsanitize=undefined -fno-sanitize-recover=all
ubsan: LDFLAGS += -fsanitize=undefined
ubsan: program_ubsan
program_ubsan: $(OBJECTS)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) -o $@
# ThreadSanitizer
tsan: CFLAGS += -fsanitize=thread
tsan: LDFLAGS += -fsanitize=thread
tsan: program_tsan
program_tsan: $(OBJECTS)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJECTS) -o $@
# 全サニタイザーでテスト
test-all: asan ubsan tsan
@echo "=== Running AddressSanitizer ==="
./program_asan || true
@echo "\n=== Running UBSanitizer ==="
./program_ubsan || true
@echo "\n=== Running ThreadSanitizer ==="
./program_tsan || true
clean:
rm -f *.o program program_asan program_ubsan program_tsan
.PHONY: all asan ubsan tsan test-all clean
使用例：
# 通常ビルド
make
# AddressSanitizerでビルド
make asan
# 全サニタイザーでテスト
make test-all
# クリーンアップ
make clean
GitHub Actionsでの自動化
.github/workflows/sanitizers.yml：
name: Sanitizer Tests
on: [push, pull_request]
jobs:
sanitizers:
runs-on: ubuntu-latest
strategy:
matrix:
sanitizer: [address, undefined, thread]
compiler: [gcc, clang]
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: |
sudo apt-get update
sudo apt-get install -y build-essential clang
- name: Build with ${{ matrix.sanitizer }} sanitizer
run: |
if [ "${{ matrix.compiler }}" = "gcc" ]; then
export CC=gcc
else
export CC=clang
fi
make clean
make ${{ matrix.sanitizer }}
- name: Run tests
run: |
case "${{ matrix.sanitizer }}" in
address)
export ASAN_OPTIONS=check_initialization_order=1:strict_string_checks=1
;;
undefined)
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
;;
thread)
export TSAN_OPTIONS=history_size=7:second_deadlock_stack=1
;;
esac
./program_${{ matrix.sanitizer }} || true
- name: Upload artifacts on failure
if: failure()
uses: actions/upload-artifact@v3
with:
name: failed-${{ matrix.compiler }}-${{ matrix.sanitizer }}
path: |
*.log
core.*
最新標準による安全性の向上
C23の新機能
C23標準7は正式に策定されましたが、コンパイラの完全サポートはまだ発展途上です。現在利用可能な機能を確認してみましょう。
// test_c23_features.c
#include
#include
// C23の機能を条件付きで使用
#ifdef __STDC_VERSION__
#if __STDC_VERSION__ >= 202311L
#define HAS_C23 1
#endif
#endif
// typeof演算子（GCC/Clangでは既に利用可能）
#ifdef __GNUC__
#define SWAP(a, b) do { \
__typeof__(a) temp = (a); \
(a) = (b); \
(b) = temp; \
} while(0)
#endif
int main() {
printf("C Standard Version: ");
#ifdef __STDC_VERSION__
printf("%ld\n", __STDC_VERSION__);
#else
printf("Unknown\n");
#endif
// typeof演算子のテスト
#ifdef __GNUC__
int x = 10, y = 20;
printf("Before swap: x=%d, y=%d\n", x, y);
SWAP(x, y);
printf("After swap: x=%d, y=%d\n", x, y);
double a = 3.14, b = 2.71;
printf("Before swap: a=%.2f, b=%.2f\n", a, b);
SWAP(a, b);
printf("After swap: a=%.2f, b=%.2f\n", a, b);
#endif
return 0;
}
コンパイルして確認：
# C23モードでコンパイル（サポートされている範囲で）
gcc -std=c2x -O2 test_c23_features.c -o test_c23
./test_c23
# サポートされている機能を確認
gcc -std=c2x -dM -E - grep -E "(STDC_VERSION|__GNUC__)"
C++の安全な代替手段
C++では、より安全な機能が既に利用可能です。
// test_cpp_safety.cpp
#include
#include
#include
#include
#include
// スマートポインタによる自動メモリ管理
void demonstrate_smart_pointers() {
std::cout "=== Smart Pointers Demo ===\n";
// unique_ptr: 単一所有権
{
auto ptr = std::make_uniqueint[]>(100);
ptr[0] = 42;
std::cout "unique_ptr value: " ptr[0] "\n";
// スコープを抜けると自動的に解放
}
// shared_ptr: 参照カウント
{
auto shared = std::make_sharedstd::vectorint>>(10);
shared->push_back(123);
auto copy = shared;
std::cout "shared_ptr ref count: " shared.use_count() "\n";
// 最後の参照が消えると自動解放
}
}
// 安全な配列アクセス
void demonstrate_safe_arrays() {
std::cout "\n=== Safe Arrays Demo ===\n";
std::arrayint, 5> arr{1, 2, 3, 4, 5};
// 境界チェック付きアクセス
try {
std::cout "arr.at(2) = " arr.at(2) "\n";
std::cout "Trying arr.at(10)...\n";
arr.at(10) = 42; // 例外が発生
} catch (const std::out_of_range& e) {
std::cout "Caught exception: " e.what() "\n";
}
// C++20のstd::span
#if __cplusplus >= 202002L
std::vectorint> vec{10, 20, 30, 40, 50};
std::spanint> span_view(vec);
std::cout "Span size: " span_view.size() "\n";
#endif
}
int main() {
demonstrate_smart_pointers();
demonstrate_safe_arrays();
std::cout "\nC++ Standard: " __cplusplus "\n";
return 0;
}
コンパイルして実行：
# C++17でコンパイル
g++ -std=c++17 -O2 test_cpp_safety.cpp -o test_cpp_safety
./test_cpp_safety
# C++20でコンパイル（std::span使用可能）
g++ -std=c++20 -O2 test_cpp_safety.cpp -o test_cpp_safety_20
./test_cpp_safety_20
まとめ
この記事で紹介したテクニックをまとめると、C/C++の安全性を大幅に向上させることができます。
開発時の必須ツール：
# 開発用コンパイルフラグ
CFLAGS="-Wall -Wextra -Werror -g -O1 \
-fsanitize=address,undefined \
-fno-omit-frame-pointer"
# リリース用コンパイルフラグ
CFLAGS_RELEASE="-O2 -DNDEBUG \
-fstack-protector-strong \
-D_FORTIFY_SOURCE=2 \
-fPIE -pie"
安全なコーディングの原則：
- 常に境界チェックを行う
- ポインタは必ずNULLチェック
- 動的メモリは必ず解放し、解放後はNULLに設定
- 整数演算はオーバーフローチェック
- マルチスレッドでは適切な同期機構を使用
サニタイザーの活用：
- 開発時は常にAddressSanitizerを有効に
- CI/CDパイプラインに全サニタイザーテストを統合
- パフォーマンステストは別途、サニタイザーなしで実施
これらのテクニックを適切に組み合わせることで、C/C++コードの安全性を10倍以上向上させることができます。確かにC/C++には危険な側面がありますが、適切な知識とツールがあれば、安全で高性能なソフトウェアを開発することは十分可能なのです。
参考文献
- CQ出版社（2020）『マイコン・組み込み開発のリスク認識入門』〈セミナー教材〉
- 独立行政法人情報処理推進機構（IPA）（2007）『セキュア・プログラミング講座 2007年版 C/C++ 言語編』
- JPCERT コーディネーションセンター（2024）『CERT C コーディングスタンダード 日本語版（最終更新 2024-08-20）』
![[入門] C/C++コードを10倍安全にする 未定義動作を防ぐ実践テクニック #C++ – Qiita](https://inmobilexion.com/wp-content/uploads/2025/06/1750435348_https3A2F2Fqiita-user-contents.imgix_.net2Fhttps253A252F252Fcdn.qiita_.com252Fassets252Fpubli-768x403.jpeg "[入門] C/C++コードを10倍安全にする 未定義動作を防ぐ実践テクニック #C++ – Qiita")
![[入門] C/C++コードを10倍安全にする 未定義動作を防ぐ実践テクニック #C++ - Qiita](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnMzLWFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkZxaWl0YS1pbWFnZS1zdG9yZSUyRjAlMkYzNTIxNTczJTJGMjZiODFmMzNmZGQ5MDMzMzMxYTk5MTUyMjE2NTkyOTE4M2U3NDZlOSUyRnhfbGFyZ2UucG5nJTNGMTY5MDUxNjE0Nj9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz02MjA3M2Y0ZTM0ZWY1ZjM5YmU1YWI0OTc4ZTg4NjU0Nw%26blend-x%3D120%26blend-y%3D467%26blend-w%3D82%26blend-h%3D82%26blend-mode%3Dnormal%26s%3Deebbbbbf6f8e3a841a51543d24314cf3?ixlib=rb-4.0.0&w=1200&fm=jpg&mark64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJUU1JTg1JUE1JUU5JTk2JTgwJTVEJTIwQyUyRkMlMkIlMkIlRTMlODIlQjMlRTMlODMlQkMlRTMlODMlODklRTMlODIlOTIxMCVFNSU4MCU4RCVFNSVBRSU4OSVFNSU4NSVBOCVFMyU4MSVBQiVFMyU4MSU5OSVFMyU4MiU4QiUyMCVFNiU5QyVBQSVFNSVBRSU5QSVFNyVCRSVBOSVFNSU4QiU5NSVFNCVCRCU5QyVFMyU4MiU5MiVFOSU5OCVCMiVFMyU4MSU5MCVFNSVBRSU5RiVFOCVCNyVCNSVFMyU4MyU4NiVFMyU4MiVBRiVFMyU4MyU4QiVFMyU4MyU4MyVFMyU4MiVBRiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPThkY2M0OWRjODAzMzg4ZGVlZjYzMDg3MDdiMmRiODZk&mark-x=120&mark-y=112&blend64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBTaGlnZW1vcmlNYXNhdG8mdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz01NWYyMTRhNGU0YmFjYTk5NGNmOWVkZTUyYzI2YzM5Zg&blend-x=242&blend-y=480&blend-w=838&blend-h=46&blend-fit=crop&blend-crop=left%2Cbottom&blend-mode=normal&s=aa1a676fe21eaf13abf498cfc34338cd)
