type punning と strict aliasing - memologue
/.JのGCC-3.4リリースの話題を追っていたら、GCC3では-O2で-fstrict-aliasingが有効だから注意せよというポスト(http://slashdot.jp/comments.pl?sid=175355&cid=537217)があった。 strict aliasing については、Radium Software Developmentさんが詳しい。これは気にしておいたほうがよさそうだ。GCCの -fstrict-aliasing の説明は次。 コンパイルされている言語に適用可能な別名規則（aliasing rule）のうち最も厳密なものをコンパイラが前提することを許します。これによって、 C（およびC++）では式の型に基く最適化を動作させることになります。例えば、ある型のオブジェクトが別の型のオブジェクトと同一アドレスに位置することは、それら2つの型がほとんど同一でない
非同期シグナルとanti-pattern - memologue
sigsafeというUNIX向けの小さなライブラリがあります。これは、「シグナルを正確に取り扱うのは非常に難しい、俺たちのライブラリを使うと随分楽になるよ」といった趣旨の、アセンブラとCで書かれたライブラリで、それなりの種類のOS、CPUがサポートされています。 このライブラリ自体の使い方、使い勝手、あるいはどう実装されているかについてはまだ把握しきれていないのですが、ドキュメントに有用な部分があるのでご紹介します。 http://www.slamb.org/projects/sigsafe/api/patternref.html です。非同期シグナルを使用したコーディングを行う際の、一種のアンチパターン集になっています。 悪い例1: signal safe ではない関数をシグナルハンドラから呼んでしまう void unsafe_sighandler_a(int signum) { pri
RAIIもどき in C __attribute__((cleanup(fn)))
gccの__attribute__((cleanup(fn))) が便利すぎる件について。 C++でコードを書くときは、RAIIとか呼ばれているイディオムを使えば、ご存じの通り、ロックしたmutexを手動で開放する必要もないですし、newしたオブジェクトを手動でdeleteする必要もないです。 void Baz::boo() const { boost::mutex::scoped_lock lock(mutex); // ... return; // lock変数のデストラクタで自動開放。手動での開放不要 }でもC言語だと、当然ながら手動で開放しないといけません。複数箇所でreturnしている場合など、タイプが面倒臭すぎ。 int foo() { pthread_mutex_lock(&mutex); // ... if (hogehoge) { pthread_mutex_unlock
memologue - シグナルハンドラを使わないでシグナルをハンドルする
「シグナルハンドラの中でできることは非常に限られているんですよ」というお話を1年半くらい前に書きましたが、この話には続きがあって、ある特定の条件下ではこの制限を緩和することができます。今回はその方法についての解説です。sigwait(3)という関数を使います。 ※ この話、うっかり書き忘れていました。ちょっとしたきっかけで思い出したので、暇があるうちに書いておきます。 ■「シグナルを待つ」処理 〜従来の方法〜 皆様、「シグナルの到着を待つ」処理を、次のように書いてしまっていないでしょうか？ // シグナルハンドラ void handler(int signo) { // この中で使って良いのは非同期シグナルセーフ(async-signal-safe)な関数のみ }を用意して、 sa.sa_handler = handler; sigaction(SIGHUP, &sa, NULL); ..
UNIXの規格について - memologue
いままで漠然と、「UNIXの規格について調べるときにはSUSv3を見る」ことにしていましたが、それでOKなのかちょっと調べてみました。 結論としては、ここ 今や ISO/IEC 9945:2002 IEEE Std 1003.1-2001 (POSIX) Single UNIX Specification Version 3 (SUSv3) の3つは，全く同じものですから、SUSだけ見れば十分だと思います。 の記述通りのようですね。 以下は、The Single UNIX Specification Version 3 - Overviewに書いてあることの要約です。 自分なりのまとめ 昔、似たような標準を作っている団体として、OpenGroup, ISO/IEC, IEEE があった。で、 ISO/IEC 9945-1(POSIX.1), ISO/IEC 9945-2(POSIX.2)
SUSv3検索プラグイン - memologue
mozdev.org に、The Single UNIX Specification, Version 3*1 を検索するためのプラグインがありました。Windowsはもちろん、FC5(x86_64)のfirefoxでも無事動きました。 (デフォルトで)firefoxのウィンドウの右上にある検索窓からSUSv3全体を検索できるっていうのは、なかなか快適です。POSIXファンの皆様もぜひ。 *1:=POSIX だと思ってもらっておけです
hogetrace - 関数コールトレーサ - memologue
でかいソフトウェアの、大量のソースコードを短時間で読む必要が生じたので、その補助ツールとしてptrace(2)ベースのLinux用関数トレーサを自作しました。こういうツール上でまずソフトウェアを実行してみて、どのファイルのどの関数がどういう順で呼ばれるか把握おけば、いきなりソースコードの山と格闘を始めるより楽かなーと思いまして。せっかく作ったので公開します。 http://binary.nahi.to/hogetrace/ straceはシステムコールだけ、ltraceは共有ライブラリ(DSO)の関数呼び出しだけ*1をトレースしますが、このツールは、実行バイナリ中の自作関数の呼び出しもトレースします。例えば再帰で1から10まで足し算するソースコードを用意して % cat recursion.c #include <stdio.h> int sum(int n) { return n ==
google-perftoolsを別のCPUに移植してみた - memologue
google-perftoolsというx86,x86_64,ppcなUNIX向けのプロファイラの(cpu-profiler部分)を、armなLinuxに対応させてみました。何かの役に立つかもしれないので、patchおよびpatch作成作業のメモを載せます。arm-v5tアーキテクチャ(ARM9系)向けの移植です。 Linux/ARM向けのソフトウェアのパフォーマンスを解析したいなぁと思うことがあったのですが、OProfileはカーネル入れ替えがめんどくさい、gprofはプロファイル専用のバイナリを作成するのがめんどくさい、プロプラな奴は興味ないということで移植しました。移植の方がめんどくさいだろという話もありますが。perftools自体の説明はこちらが便利です。あーそういえばAndroidもARMでしたっけ? パッチ http://binary.nahi.to/google-perfto
memologue - C/C++の定数の型の話, C90/C99の差分のびみょーな話
Cのソースコードに m = 195; とか n = 0xffffffff; とか書いたときの定数（右辺）の型って、なんであるかご存じでしょうか？ また、C90(1990年版のISO C言語規格)とC99(1999年版のそれ)ではその型が微妙に異なったりすることがあるんですが、ご存じでしょうか？ さらには、お使いのマシンがILP32であるかLP64であるかLLP64であるかによっても、微妙に型が違ってきたりするんですが、それについてはどうでしょうか? えーもちろん、普段は「Uがついてなかったらint, Uがついてたらunsigned intジャネーノ？」くらいの理解でも殆ど不自由しないわけですが、詳細な理解がないとハマるケースも稀にあります。 私はというと、上に書いたような事は、C90/99の差違を除いてはだいたい理解しているつもりだったのですが、C90/99の差異について無頓着だったがため
マルチスレッドと共有変数 - volatile?なにそれ。 - memologue
複数のスレッドから共有する変数(典型的にはグローバル変数)を操作する際、どんな注意事項があるか？という話題です。プラットフォームはPOSIXを仮定します。pthreadのお話です。 まず、一口に「複数のスレッドで変数を共有」といっても、おおまかにいって次のような状況が考えられます。 読むスレッドしか存在しない 読むスレッド、書くスレッドの両方が存在する 書くスレッドは、read-modify-write動作を行う 書くスレッドは、read-modify-write動作を行わない 変数の更新(メモリ操作)がアトミックに行える*1 変数の更新(メモリ操作)がアトミックに行えない*2 順に見ていきましょう。観点は、「(1) volatile修飾が必要か」「(2) mutexによるロックが必要か」の2点です。 まず、「1. 読むスレッドしか存在しない」ケース。例えば、 static const c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
