C言語をマスターしたい人はGCCのバージョン14を使いましょう - pyopyopyo - Linuxとかプログラミングの覚え書き -
C言語（C++を含む）を習得したい人，ポインタを勉強したい人はgcc-14を使いましょう．難しいところは gcc-14 が丁寧に解説してくれます C言語の難しいところ 例を示します．C言語で記述された，たった６行のソースコードです int main() { int buf[10]; buf[10] = 0; return 0; } このソースコードには問題があります．初見でわかるでしょうか？ : : : 問題があるのは buf[10]=0 の部分です．C言語でやりがちなミスですが，これがバグやセキュリティホールの原因になります． C言語が難しい理由は二つあります．この手の問題を見逃しやすい点と，この手の問題を理解することが難しい点の二つです gcc 14 に解説してもらいましょう 上記の６行のソースコードをgcc14を使ってコンパイルしてみます ソースコードのファイル名は test.c と
GCC - 3.9. Static 解析を制御するオプション ¶ [ja]
3.9 Static 解析を制御するオプション ¶ -fanalyzer ¶ このオプションを使用すると、プログラム フローの static 分析が有効になり、コード内の「興味深い」プロシージャ間パスを検索し、そこで見つかった問題に対して警告を発行します。 この分析は、他の GCC 警告よりもはるかに高価です。 技術的に言えば、コンパイル中のコードのカバレッジに基づいたシンボリック実行を実行します。それは健全でも完全でもありません。 false ポジティブと false ネガティブが存在する可能性があります。これはプログラムの正しさを証明するツールではなく、バグを発見するツールです。 このリリースでは、アナライザーは C コードでの使用にのみ適しています。 このオプションを有効にすると、次の警告が有効になります。 -Wanalyzer-allocation-size -Wanalyzer-
革命の日々！ __attribute__(alloc_size) を使わないと_FORTIFY_SOURCE を活かせないよ。という話
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
D_FORTIFY_SOURCEを使う - hidetzu's blog
これもバッファーオーバーフロー検出に関するお話。 gcc4からの機能です。 使い方 (o1以上の最適化オプションをつける) gcc -O1 -D_FORTIFY_SOURCE=1 foo.c検出時は、下記のいずれか コンパイル時 実行時 これの機能のすごいとこは、リリースビルドで使えるということ。 gオプションがいらないので、リリースするモジュールにも積極的に使えるということ。 #include <string.h> static char buf[6]; int main(int argc, char** argv) { strcpy(buf, argv[1]); return 0; } こんなソースを実行すると下記の感じになる。 ======= Memory map: ======== 08048000-08049000 r-xp 00000000 08:01 10888991 /ho
CおよびC++のコンパイラ・オプション強化ガイド - The Linux Foundation
このドキュメントは、C および C++のネイティブ（またはクロス）ツールチェーンを使用して、信頼性が高くセキュアなコードを提供するために貢献するコンパイラとリンカのオプションに関するガイドです。コンパイラオプションの強化の目的は、潜在的な攻撃や誤動作に対するセキュリティメカニズムを備えたアプリケーションバイナリ（実行可能ファイル）を生成することです。また、強化されたコンパイラオプションは、最新のオペレーティングシステム（OS） の既存のプラットフォーム セキュリティ機能とうまく統合するアプリケーションを生成するはずです。コンパイラコンパイラを効果的に設定することは、コンパイラーの警告、静的解析、デバッグインスツルメンテーションの強化など、開発中にもいくつかの利点をもたらします。 本ドキュメントは、以下の方々を対象としています： 組み込み機器、モノのインターネット機器、スマートフォン、パソコ
AddressSanitizerを試す - cuspy diary
C言語 Advent Calendar 2016 16日目です。 clang 3.1, gcc 4.9以降にメモリ関連の不正な操作を検出するAddressSanitizerという仕組みが入りました。 二重freeやバッファオーバーフローなどCプログラミングにありがちなメモリ操作を検出できるので、ソフトウェアの品質向上だけでなく、セキュリティ対策としても有用です。 以下に思いつく限りのメモリの不正操作を実際に試してみました。 (1) スタックオーバーフロー(1.1) 正方向の書き込み [stack_overwrite.c] (https://github.com/hamano/santest/blob/master/tests/stack_overwrite.c)(1.2) 正方向の参照 [stack_overread.c] (https://github.com/hamano/santes
【C】可変長マクロで引数なしを受け渡すには ##__VA_ARGS__ (gcc拡張)
C言語のマクロの引数の最後に ... を指定することで任意個の引数を取り、 __VA_ARGS__ で参照できる：
C++ コンパイル時「出力」 ～C++にできないことはない～ - Qiita
これは、 C++ でコンパイル時に出力まで済ませようとした話です。 コンパイラは GCC に限ります。 はじめに もうすぐクリスマスですね！ クリスマスにすることといえば……、 そう、コンパイル時処理ですね！！ コンパイル時処理 C++ のコンパイル時処理は非常に強力で、様々なことがコンパイル時にできてしまいます。 普通はコンパイル時に決まる定数の計算に使われますが、これを悪用利用してコンパイル時に処理がすべて終わるようなものも書くことができます。 例として、コンパイル時 FizzBuzz を書いてみます。 #include <array> #include <string_view> #include <algorithm> #include <concepts> #include <iostream> template <std::unsigned_integral T> conste
printfに4285個アスタリスクをつけるとclang++が死ぬ - Qiita
def check(n) s = "*"*n f = open("test.cpp","w") f.puts <<EOS #include <cstdio> int main(){ (#{s}printf)("Hello World\\n"); } EOS f.close() return system("clang++ test.cpp") end check(ARGV[0].to_i) $ ruby check.rb 10000 clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 10.0.1 (clang
gprofを使いこなす - minus9d's diary
C/C++のコードの速度を改善するときに有効な方法は、処理時間を多く消費する関数を見極めて、その関数を改善することである。どの関数が(1)どれだけ処理時間を消費するか、(2)何度呼ばれているか、(3)どの関数を呼んでいる/どの関数に呼ばれているか、などを測定する行為をプロファイリングといい、その手助けをするツールをプロファイラと呼ぶ。今回はC/C++のプロファイラとして有名なgprofの使い方を紹介する。 プログラムの例 GNUプロファイラーによるコード処理速度の向上 のコードを参考にして作成した以下のコードをgprofでプロファイリングしてみよう。main()はa()とb()を100000回呼ぶ。b()はa()の約4倍時間を消費する。またmain()自身も、a()とb()を呼び出してその結果を待つ以外に、a()の約1/3の時間を消費する。 // main.cpp #include <cs
PIE (位置独立実行形式) を作成する - bkブログ
PIE (位置独立実行形式) を作成する 通常、PIC (位置独立コード) は共有ライブラリに用いられますが、Linux 上で最近の GCC, Glibc および GNU Binutils を使うと、実行ファイルも位置独立にすることができます。本記事では PIE (位置独立実行形式) を作成する方法と特徴を紹介します。 PIE の基本 それでは例を見てみましょう。次のようなファイル foo.c があるとします。 #include <stdio.h> void foo() { printf("hello\n"); } int main() { foo(); return 0; } このファイルを -fPIE というオプションをつけてコンパイルし、 -pie というオプションをつけてリンクすれば PIE を作成できます。出来上がったファイルは普通に実行できます。 % gcc -c -fPIE
静的ライブラリのリンク時にundefined referenceエラーが出る(gcc)
静的ライブラリのリンク時にundefined referenceエラーが出る(gcc) 概要 gccでリンク時にundefined referenceエラーが出る場合がある。 通常はオブジェクトやライブラリの指定忘れが原因であるが、 静的ライブラリをリンクする順番に間違いがあって出る場合もある (自分でMakefileを書く場合にこのミスをすることが多い) リンクの順番には依存性があり、あるオブジェクトが静的 ライブラリ内の関数を呼び出すときには呼び出される側の ライブラリは「後で」リンクする必要がある。 例えば foo.o が静的ライブラリ libfoo.a 内の関数を使用している、つまり foo.o → libfoo.a という依存関係があるとき、 g++ -o foo libfoo.a foo.o とするとundefined referenceエラーが出る。従って g++ -o fo
-pthread を忘れると std::thread で例外が発生する仕組み - Qiita
std::thread を使用したソースを -pthread オプションを付けずにビルドすると、ビルドエラーにならずに実行時エラーになる仕組みが気になったので調べてみました。 パスやら何やらは x86-64 版の Gentoo Linux のものです。他ディストリビューションでは微妙に異なるかもしれません。 -pthread オプション g++ や clang++ で C++11 以降に実装された std::thread を使おうとすると、オプション -pthread が必要です。これを忘れると、スレッドを実行しようとした時点で例外が発生してしまいます。 #include <iostream> #include <thread> void func() { std::cout << "Hello!" << std::endl; } int main() { std::thread(func
OpenMPの基本的な使い方 - Qiita
サーバサイドの大規模計算・組み込み系・ゲームプログラミングなどの分野ではしばしば高速化を求められることがある。 その中でも、スレッド並列に関する高速化はマルチコア化の波で近年特に求められている。 この記事ではスレッド並列にOpenMPを利用した高速化手法についての基本的な部分を紹介していく。 *言葉の解釈によっては適切でない部分や、OpenMPの正しい使い方から外れた部分があるかもしれません。 *2017.02.16 記事の一部に書き途中・適切ではない記載があったので更新しました。 スレッド並列化とは？ スレッド並列化とは、近年のPCによく使われているマルチコアのCPU上で行われる並列化のことである。CPUによっても変わるが、主流のIntel社製Core iシリーズのCPUなどでは1コアで2スレッドまでのスレッドを持つことができる。 例に、2016年の新モデルMacBookProの13イン
Why do I get a C malloc assertion failure?
I am implementing a divide and conquer polynomial algorithm so I can benchmark it against an OpenCL implementation, but I can't get malloc to work. When I run the program, it allocates a bunch of stuff, checks some things, then sends the size/2 to the algorithm. Then when I hit the malloc line again it spits out this: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->
mrubyでmemsetやmemcpyが少ない理由．
リンク先には，次のような記述があります． Looks like on ARM architecture, GCC and other compilers may mis-optimize memcpy and assume certain memory alignment, whichcreates errors on unaligned access. To avoid this, either don't use memcpy, or, cast the pointers to char* to disable this misoptimization. More details here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 意訳) ARM みたいに memcpy で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
stdout thread-safe in C on Linux?
Using the GNU Compiler Collection (GCC)
Difference between -pthread and -lpthread while compiling
VisualStudio 2015 で Linux アプリの開発＆デバッグ