Entry

気ままに Ruby hack - st.c が微妙にリークしている気がする

2008年09月01日

ruby-lang の ML にも入ってないし,ここに書いておこうっと。st.c というのは,Ruby のシンボルをハッシュテーブルで管理する部分です。なんかここ最近ハッシュのことばっか書いてるんですけど,それはたまたま。

なんかいろいろあるんですけど,とりあえず,st_copy() という関数を見てみます。ハッシュテーブルをコピーする関数です。

st_table*
st_copy(old_table)
    st_table *old_table;
{
    st_table *new_table;
    st_table_entry *ptr, *entry;
    int i, num_bins = old_table->num_bins;

    new_table = alloc(st_table);
    if (new_table == 0) {
        return 0;
    }

    *new_table = *old_table;
    new_table->bins = (st_table_entry**)
        Calloc((unsigned)num_bins, sizeof(st_table_entry*));

    if (new_table->bins == 0) {
        free(new_table);
        return 0;
    }

    for(i = 0; i < num_bins; i++) {
        new_table->bins[i] = 0;
        ptr = old_table->bins[i];
        while (ptr != 0) {
            entry = alloc(st_table_entry);
            if (entry == 0) {
                free(new_table->bins);
                free(new_table);
                return 0;
            }
            *entry = *ptr;
            entry->next = new_table->bins[i];
            new_table->bins[i] = entry;
            ptr = ptr->next;
        }
    }
    return new_table;
}

このルーチンのここら辺。行番号でいうと,366行目あたりです。

        while (ptr != 0) {
            entry = alloc(st_table_entry);
            if (entry == 0) {
                free(new_table->bins);
                free(new_table);
                return 0;
            }
            :
        }

新しいテーブルのエントリ(entry)についてメモリを確保していて,失敗したら,これまで作ったエントリを解放しています。

で,これなんですけど,実はこのハッシュテーブル,チェイン法を使ってるので,それぞれの要素が連結リストになっていたりします。大げさだけど,図示するとこんな感じか(ペイントで描いた)。

st_table の図

new_table->bins を新しく作って,それにくっつく entry を while-文でクルクル回しつつくっつけてるわけですけれど,entry の確保に失敗した時に,new_table->bins と new_table を free(3) しているだけで(図中黄色の部分),これまでくっつけた entry を free(3) していません。これでいいんだろうか。

まぁ,実際問題として,コピー時 malloc(3) に失敗するケースってのはレアケースだと思うので,いいっちゃいいのかなあ……とも。つか,この関数の呼び元をそもそも読んでないから,全体の中でどうなってるのかはよく分からなかったりする。

実のところ,このモジュールは,全体的に calloc(3) や malloc(3) の戻り値を見ていなくて,この関数だけやけに丁寧な後始末をしていたりします。失敗した時は OS に例外を渡して,セグメンテーションフォルトで落とすってポリシーなんだと思えば,こっちのがむしろ丁寧な措置なんじゃないかとも思えてしまいます(よく分からないけど)。

先日,ソースが詳細設計書なんてトンデモなことを言っている人について書いたけれども(参照:qune: 詳細設計書はソースに書いてあるとか言っている人はよほど立派なソースを書くんだろうなと思った),こゆときに設計書があれば何が正しいかすぐ分かるんですよね。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN