丁稚な日々

◆[るびま] 0013号

_ 出ました。
みなさんおつかれさまでした。

◆ChangeLog

_ 昨夜commitしてすぐ寝ちゃって、寝てからChangeLogにML番号入れるの忘れたことに気付いたんだけど、すぐにまつもとさんが入れてくれてました。ありがたや。

◆[mswin32] VC++8

_ artonさんががんばっておられるようですが、MSVCR80.dllは、本来単にエラー終了すべきところで容赦なくデバッガに落ちるようです。

_ というか、リリース版でデバッガに落ちるコードがあるわけがないのでつまりMicrosoftが間違えてデバッグビルドをリリース版として出してるんじゃないかとか思ったり思わなかったりしてるところでやる気がなくなってます...

◆[Web] swin

_ includeの順番ですが、できれば放っておかないで下さい。
yarvだけじゃなくて、1.9でもコンパイル通らないですー。

_ あと、extconf.rbに、have_libraryして必須ライブラリが見つからなかったらcreate_makefileしない、という変更も希望。

◆[mswin32] VC++8

_ APIドキュメントってこれですかね?
これを見る限りでは、_get_osfhandle()は引数fdがおかしかったらエラーを返すべきでクラッシュするべきではないように思えます。実際、VC++7.1まではそう動作するんだし。

_ 以上の前提を踏まえてcrtのソース(osfinfo.c)を見てみましょう。
実際はVC++8でも(VC++7.1までとソースの書き方は異なりますが)、単にエラーを返すように書かれているように見えます。マクロ_VALIDATE_CLEAR_OSSERR_RETURNがその部分です。
で、このマクロの中身(internal.h)を見ると、さらにその中でマクロ_ASSERT_EXPRとマクロ_INVALID_PARAMETERが使われています。

_ 前者の中身(crtdbg.h)を見ると、_DEBUGを定義せずにコンパイルすれば何もしないけれど、定義してあると_CrtDbgReportW()を呼び出してデバッガに落ちることになっています。

_ また、後者の中身(internal.h)は、_DEBUGを定義せずにコンパイルすれば適当な引数で_invalid_parameter()を、定義してあればちゃんとした引数で_invalid_parameter()を呼び出すことがわかります。
で、この_invalid_parameter()の中身を追うのが非常に面倒なのですが、私の見た限りでは、ユーザーが必要なフックを設定しない限り何もしないように見えます。

_ 以上から、ランタイムが_DEBUGを定義してコンパイルされていない限り、_get_osfhandle()はデバッガに落ちないはずだということがわかりました。
というわけで、現在見えている現象から類推するに、我々が使わさせられているMSVCR80.dllは_DEBUGを定義してコンパイルされた、ということがわかります。
これを確認する最も手っ取り早い方法は、MSVCR80.dllがWin32 APIのDebugBreak()をインポートしているかどうか確認することです。
実際、VS2005配布物中のMSVCR80.dllはDebugBreak()をインポートしています。
私はたまたまVS2005配布物でない、ちょっと古いバージョンのMSVCR80.dllも持っているのですが、それは_DEBUGを定義せずにコンパイルされたものらしく、DebugBreak()はインポートしていませんし、当然、以上のような問題は起きません。

_ 結論としては、私は、MSが間違えて_DEBUGを定義してコンパイルしてしまったMSVCR80.dllを配布してしまったのではないかと考えています。
間違えじゃなくて今後はこういう仕様なのかなあ。だったらイヤスギ。
と、いうのが、昨日のやる気がなくなってる理由です。

◆[mswin32] VC++8 つづき

_ ふむふむ。

_ すると、_INVALID_PARAMETERの方にひっかかってるはずである、という話になるんですね。それならそれで納得はできます。
_set_invalid_parameter_handler()を呼んでおくだけですからね。
でも、私が試したときは、その前の_ASSERT_EXPRに引っかかったような気がしてるわけで、そこが気になってるのです。記憶違いかなあ。

_ registry.rbの方は、確認してないのでにんともかんとも。

◆[mswin32] VC++8 つづきのつづき

_ 言うよりやる方が早い気がしてきた。

Index: win32/win32.c
===================================================================
RCS file: /home/cvs/ruby/win32/win32.c,v
retrieving revision 1.185
diff -u -1 -p -r1.185 win32.c
--- win32/win32.c	14 Feb 2006 04:49:01 -0000	1.185
+++ win32/win32.c	23 Feb 2006 09:50:33 -0000
@@ -412,2 +412,9 @@ static void init_stdhandle(void);
 
+#if _MSC_VER >= 1400
+static void invalid_parameter(const wchar_t *expr, const wchar_t *func, const wchar_t *file, unsigned int line, uintptr_t dummy)
+{
+    // nothing to do
+}
+#endif
+
 //
@@ -422,2 +429,6 @@ NtInitialize(int *argc, char ***argv)
 
+#if _MSC_VER >= 1400
+    _set_invalid_parameter_handler(invalid_parameter);
+#endif
+
     //

_ あら、さくっとnmake -l test-allが通るね(いや、Eとかは出るけど)。

_ 結論としては、私間違い、artonさん正しいということで。
お騒がせしました。

_ しかし、1.8はまだtest-allで落ちるなあ。ちぇ。

◆誕生日

_ Rubyは、えーと、13歳かな?

◆[mswin32] VC++8

_ 1.8で、外部ライブラリが絡むもの以外は0E0Fになった。
我ながらびっくりだけど、とりあえずcommitしておく。

_ registry.rbの問題はこちらでは何も起きてないのでさっぱりわからないまま。

_ ううむ、そもそもmswin32では1.8ではtest-allはサポートしてないので(だいたい動くけど)、runner.rb直打ちなんですよねえ、うちでも。
なんかの拍子に直るか現象が隠れるかしたか、環境依存なのか、謎です。