FC2ブログ

2011総括

春先早々の大地震だけが記憶に残る一年になってしまった。

”波”で飯食ってた事もあるので津波の仕組みや怖さも重々承知していたつもりだったし、奥尻の惨状も実際に見て知っていたつもりだったが、とてつもない映像をいやというほど見せつけられるとさすがに普通の精神状態ではいられなくなるほどの惨事だった。
昨年来からの体調不良も続いてボランティアにも行けず、雀の涙ほどの募金をした程度で、情けなさを抱えて悶々とし続けた一年。来年はボランティアにも行きたいんだけどもなぁ。

実務の方はというと、一年がかりのプロジェクトで仕事を探す手間が無くて大層助かった年ではある。
C#(WPF)でのアプリケーション開発は、思惑どおりそこそこうまく仕上がったと言えるんだが、興味の一つだった依存性注入(MEF)は今ひとつ消化不良感が残るので、またどこかできちんと仕上げたいという気持ちも。

業界でいうと、この界隈は特に何もびっくりすることもなく、新しい事もなく。
COBOLを知る人が居なくなったにも関わらず、意味なくCOBOL資産がはびこっているのも相変わらず。

おしなべて、まぁまぁ無難にこなした一年と言える。よくはやったけど進歩はそれほどなかったな、みたいな。

さて2012年。なんちうか年齢的にも大台に乗ってしまうわけで。どうしよう。
年度末までは継続業務なので、それなりにこなすしかないわけだが、その先・・
ちょっと真剣にFrameworkでも考えるかぁ?もっと幅を広げてソリューション考えるか?そんな力が今更出るのか?
Celeron2GHzのFreeBSD機でブログ書いてるようなやつがそんなでかい風呂敷広げられるのか?

あ、そうか、まずマシンの新調からだなっ(にやり
スポンサーサイト

誰もやらないreaddirの不思議

ディレクトリの一覧をとるのに使う、readdir関数。
struct dirent *readdir(DIR *);


誰もが良く使う関数なんだが、遭遇したのはこんなの。
while ((pent = readdir(pdir)) != NULL) {
    foo(pent->d_name);
    ....
}
...

void foo(char *p)
{
    if (strlen(p) < LIMITSIZE) {
        memset(p, 0, sizeof p);
    }
}

なんらかの条件でd_nameの中身をクリアしようとしたらしい。
もちろんfoo内ではpはポインタなのでsizeofの値は4Byte(64bitなら8Byte)にしかならないが、このつまらんバグは問題ではない。

struct direntの定義を見ると、d_name[255 + 1]という記述が見つかり、d_nameは256Byte確保されていると見えてしまうわけなんだが、実はそうじゃない。
d_nameに格納されるファイル名は255までですよ、というアピールでしかなく、実際にd_nameが256Byte確保されているわけじゃないのは、次々取得するdirentを見るとなんとなくわかる。

実際にはファイル名を格納するのに十分なサイズが確保されているに過ぎないようで、
先のコードの例では、例えばファイル名が'.'だった場合、8Byteを0で潰すと、次の何かを塗りつぶすことになる。

FreeBSD(32bit)の場合、0で潰したファイルの次のファイルが取得できず飛び飛びにしか取得できなかった。
Linux(64bit)の場合、0で潰した次のreaddirはエラーとなりNULLが返ってきてしまった。

まぁ、上のコードのように d_name を書き換えようなんて状況は万に一つもありえないわけで、まったくどうかしてるぜ、っちうような話であるが、実際に遭遇してみるとd_name[255+1]の定義に騙されて悩んでしまったりしたのである。
プロフィール

f_yamaki

Author:f_yamaki

アクセスカウンタ
最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
ブロとも申請フォーム

この人とブロともになる

ブログ内検索
RSSフィード
リンク