ドリコムRSSのClip!の削除も問題なく動くようになった

結局、原因は cookie 回りの処理に問題があることが判明

• 通常の「取得」が問題なく、削除用の「取得」で問題が出たのは、後者の cookie 格納領域のサイズが、前者の cookie 格納領域の半分しかなかったため → 要するに、メモリ領域破壊が起きてて、スタックフレームにまで被害が及んでいた
• Visual C++ 6 でビルドしたロードモジュールでは問題が発見できていなかっただけで、実は通常の「取得」にも問題があった。Visual Studio 2005 の VC++ でビルド、デバッグしていて発見。これは、自前の http 通信処理内の cookie の取り扱いに問題があった。これもメモリ破壊。

原因がわかったので、ソースを修正。問題なく動くようになりました。

なぜか日本時間なのに夏時間になる(1時間ずれる)

ついでに、バッドノウハウを1つ。Visual Studio 2005 でビルドしたときにリンクされるランタイムモジュールの「これはひどい」仕様に遭遇。環境変数 TZ を設定した状態で、localtime() とかを使うと、(アメリカが夏時間の間は)日本時間(JST)でも無条件で夏時間にされてしまうんですね。ちゃんと MSDN に書いてある(笑) なので、TZ が設定されてて、かつ、タイムゾーンが JST のときは強制的に夏時間フラグを off にするコードを入れてしまいました。日本時間以外は考慮してません。

このマイクロソフトの仕様だと、夏時間の開始・終了タイミングが異なる国(ヨーロッパ各国とか)でも困るんじゃないかな? 解決方法は TZ を設定せず、Windows のインストール時(とかコントロールパネル経由とか)に設定したタイムゾーンをそのまま使うこと。ってことみたい。

もう1つ、バッドノウハウ

sniffer とかで観測しているとデータを受信していることが確実なのに recv() が返す受信バイト数が 0 になることがある問題が Windows にはあって(滅多に発生しないんだけど、なぜかドリコムのサーバと通信しているときだけは頻繁に発生する)、select() で受信イベントをキャッチしてから Sleep(10) した後、recv() するようにすることで解決します。Sleep(5) だとうまくいかないときがたまにあるので、Sleep(10) にしてみました。なんてアバウト。そういえば、ハードウェアを直接いじるプログラムでは、なぜかおまじない「Sleep(0) を入れる」を唱えると嘘のように何事もなく問題が消滅する、という話を聞いたことがあります。いまはコンパイラが賢いのか、Sleep(0) のままだとコンパイル時にコードが削除されてしまうようなので、0 より大きい値を指定する必要があるみたいですけどね。