g++ だと正常動作 ・ bcc32 だと異常終了

質問

cygwin上で g++ でコンパイルすると正常に動作し、
windows上で bcc32 でコンパイルすると正常に動作しない（おそらく不正メモリアクセスで強制終了してしまう）という現象で困っています。
g++, でも bcc32 でもコンパイルは通ります。

プログラムは長いのでこちらに載せるのは困難ですが、言語がC++のコンソールアプリケーションで、 windows の APIは使っていません。

デバッグを行った結果、停止してしまっているのは与えてやるデータによってまちまちですが、fopen()の内部であったり、rename()であったり、string型の a, b, c, d において、a+b+c+d と連結操作を行った場合などです。ちなみにfopen()やrename()に与える引数は, ちゃんとしたファイルへのパスとなっていることも確認しています。

http://www.nabble.com/-ruby-dev:28230-bcc32-memory-manager-t942132.html
にあるように、bcc はメモリ関連のバグがあるようですが、このケースもコンパイラのバグと考えてよいのでしょうか？ また、上記URLでは usebormm.lib をリンクすると動作するとありますが、 無償版を使っているためこのファイルが見当たりません。

どう対処してやればよいでしょう。
ソースを載せられないので、わかりにくい質問かとは思いますが、よろしくお願いします。

回答No.2

MrBan · ベストアンサー

再現コードがないと、なんとも言えないのは確かです。
まず、問題を切り分けるために、
・(現状の環境なりを保存した)
・内部処理を少しずつ削っていく
・どこがなくなった時点で現象が出なくなるのか確認
などを行ってみてください。

無償版 bcc のメモリ管理が甘いのは、割りと有名な話なのではないかと思いますが(以前別の掲示板でも見たことあり)、
コンパイラ/ライブラリのバグよりは、おそらくご自身のコードのバグではないかと思います。
# もしくは、ご自身のコードが標準仕様に準拠しておらず、
# 特定のコンパイラに依存してるとか。
# (マルチ対応前提ならこれもバグですが)

お礼

ご回答ありがとうございます。
原因はやはりご指摘の通り自分のミスでした。
#1さんのお礼欄にも書いたのですが、かなり初歩的なミスでした。

>・(現状の環境なりを保存した)
>・内部処理を少しずつ削っていく
>・どこがなくなった時点で現象が出なくなるのか確認

の実践までは至らなかったのですが、今後、こちらの方法を参考にさせていただきます。

お騒がせいたしました。

回答No.1

jacta

> ソースを載せられないので、わかりにくい質問かとは思いますが、よろしくお願いします。

これだけではどうしようもありません。
プログラム全体は必要ないので、現象を再現可能な最低限の抜粋だけでも載せていただかないと...

> このケースもコンパイラのバグと考えてよいのでしょうか？

メモリ関連のバグというのは、ランタイムライブラリの話であって、コンパイラ自体ではありません。
なお、当て推量に過ぎませんが、たぶん質問者さんのプログラムのバグだと思います。

お礼

> たぶん質問者さんのプログラムのバグ

まさにその通りでした。
プログラミングのバグにおいて、まずは自分を疑えとはまさにこのことですね（苦笑）
再現性がないバグだったのと、cygwinでは動いた点で自分のせいではない！と高をくくっていました。

デバッグを繰り返した結果、原因は、プログラム本体とは遠く離れた、自前のハッシュテーブルで、キー用のバッファをmallocで得る際に、

if((this->key = (char *)malloc( sizeof(char) * strlen(key))) == NULL){
　fprintf(stderr, "memory is busy.");
　exit(1);
}
strcpy(this->key, key);

とstrlenに+1を忘れ、char *key のnull文字のスペースを確保していなかったという初歩的なミスでした。
gccでうまくいっていたのは、幸にも（不幸にも）文字列の後ろがnull文字で埋まっていたからで、bcc32でコンパイルしたプログラムはnull文字で埋まっていなかった場合に強制終了してしまっていたようです。
なので、再現性のないエラーだったんだと思います。

お騒がせいたしました。