[#12387] reducing logical operation — "Nobuyoshi.Nakada" <nobu.nakada@...>

なかだです。

17 messages 2001/03/07
[#12388] Re: reducing logical operation — EGUCHI Osamu <eguchi@...> 2001/03/07

えぐち@エスアンドイー です。

[#12389] Re: reducing logical operation — nobu.nakada@... 2001/03/07

なかだです。

[#12391] Re: reducing logical operation — EGUCHI Osamu <eguchi@...> 2001/03/07

えぐち@エスアンドイー です。

[#12404] fork in threads — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

14 messages 2001/03/09

[#12405] at_exit — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

15 messages 2001/03/09
[#12409] Re: at_exit — matz@... (Yukihiro Matsumoto) 2001/03/10

まつもと ゆきひろです

[#12411] Re: at_exit — keiju@... (石塚圭樹) 2001/03/10

けいじゅ@日本ラショナルソフトウェアです.

[#12425] bignum % の結果が負数になることがある — Hisayasu Nakao <h-nakao@...>

最近、ruby-1.6.2を使い出したばかりの中尾です。

39 messages 2001/03/12
[#12427] Re: bignum % の結果が負数になることがある — WATANABE Hirofumi <eban@...> 2001/03/12

わたなべです。

[#12463] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/13

In message <4518-Mon12Mar2001145434+0900-eban@os.rim.or.jp>

[#12464] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/13

まつもと ゆきひろです

[#12466] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/13

In message <984469222.234203.1007.nullmailer@ev.netlab.zetabits.com>

[#12475] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12476] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984550885.417146.3670.nullmailer@ev.netlab.zetabits.com>

[#12480] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12481] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984553493.009507.3747.nullmailer@ev.netlab.zetabits.com>

[#12488] Re: bignum % の結果が負数になることがある — matz@... (Yukihiro Matsumoto) 2001/03/14

まつもと ゆきひろです

[#12493] Re: bignum % の結果が負数になることがある — Takahiro Kambe <taca@...> 2001/03/14

In message <984579430.080967.5569.nullmailer@ev.netlab.zetabits.com>

[#12578] require 'win32api' — Kazuhiro NISHIYAMA <zn@...>

require 'win32api'のエラーメッセージがわかりにくいと

21 messages 2001/03/20
[#12579] Re: require 'win32api' — nobu.nakada@... 2001/03/20

なかだです。

[#12598] Re: require 'win32api' — nobu.nakada@... 2001/03/21

なかだです。

[#12582] finalizer problem — keiju@... (Keiju ISHITSUKA)

けいじゅ@日本ラショナルソフトウェアです.

20 messages 2001/03/20
[#12583] Re: finalizer problem — matz@... (Yukihiro Matsumoto) 2001/03/20

まつもと ゆきひろです

[#12585] Re: finalizer problem — keiju@... (石塚圭樹) 2001/03/20

けいじゅ@日本ラショナルソフトウェアです.

[#12591] Re: finalizer problem — matz@... (Yukihiro Matsumoto) 2001/03/20

まつもと ゆきひろです

[#12619] Re: finalizer problem — keiju@... (石塚圭樹) 2001/03/22

けいじゅ@日本ラショナルソフトウェアです.

[#12605] extern inline (ruby.h) ruby-1.6.3 — WATANABE Tetsuya <tetsu@...>

渡辺哲也です。

17 messages 2001/03/22
[#12606] Re: extern inline (ruby.h) ruby-1.6.3 — matz@... (Yukihiro Matsumoto) 2001/03/22

まつもと ゆきひろです

[#12607] Re: extern inline (ruby.h) ruby-1.6.3 — WATANABE Tetsuya <tetsu@...> 2001/03/22

渡辺哲也です。

[#12608] Re: extern inline (ruby.h) ruby-1.6.3 — matz@... (Yukihiro Matsumoto) 2001/03/22

まつもと ゆきひろです

[#12674] Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp>

21 messages 2001/03/25
[#12675] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/26

まつもと ゆきひろです

[#12678] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/26

[#12681] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/26

まつもと ゆきひろです

[#12687] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/27

[#12688] Re: Was: [rubyist:0454] Re: to_str — matz@... (Yukihiro Matsumoto) 2001/03/28

まつもと ゆきひろです

[#12710] Re: Was: [rubyist:0454] Re: to_str — Kenichi Komiya <kom@...1.accsnet.ne.jp> 2001/03/31

[ruby-dev:12654] Re: require 'win32api'

From: nobu.nakada@...
Date: 2001-03-24 02:36:17 UTC
List: ruby-dev #12654
なかだです。

At Sat, 24 Mar 2001 02:43:30 +0900,
arton <arton@geocities.co.jp> wrote:
> とりあえず第1報ということで。
> 1.6.3に無理やりパッチですが(最初のハンクだけ手作業)

  どうもです。

> なんか、ent->addr が異常値になるので、LoadLibararyしたハンドル値を渡し
> てGetProcAddressを再度かける方向で今、見てます。

  小さいサンプルでは動いたような気がしたんですが…。ただその後
スクリーンセーバーになったまま抜けられなくなってリセットしたの
で、そのソースは失われて確認不能(^^;。

> Win32がファイル名の大文字小文字区別しないシステムだからと言って、やり過
> ぎな気もしないでもないですが、確かに救えれば嬉しいかも?

  まぁどーでもいいじゃんという気もするのは確かなんですが。サン
プルコードとかは全部 "Win32API" になってるのに、なんでわざわざ
違うことしてハマるかな、とか。

> 単純に、デバッガをヘルプするためのAPI(というかDLL)という分類個所という
> 意味だと思います。

  システムの時期によってはロードするライブラリをかえなきゃいけ
ないということでなければ、どちらでもいいんですけど。その場合は
LoadLibraryEx() を二回試せばいいだけですが、なんかめんどくさい
し。

At Sat, 24 Mar 2001 03:51:07 +0900,
arton <arton@geocities.co.jp> wrote:
> 下のは、Init_Win32APIしかExportされていないから、シンボルとしてのInit_win32api
> は見つかったけどGetProcAddress()に失敗した場合(ruby-dev[12598]を当てて
> ないので、当てれば変わるのかも)。

  export されてないのまで拾っちゃうのか。

> #SEGVになったのは、ImageHelpが内部でロードしたモジュール内の「仮想アドレ
> ス」ということで、多分、Baseを足してやればいいのかも知れませんが、固く
> GetProcAddress()をやり直してみました。

  イテレータの中で GetProcAddress() を呼ぶことに問題がなければ、
そっちでやった方が export されてないものにだまされるのも避けら
れるかも知れません。

> 最後から2番目の!は、ALLOCA_Nが
> .\..\dln.c(1317) : error C2143: 構文エラー : ')' が 'type' の前に必要で
> す。
> .\..\dln.c(1317) : error C2059: 構文エラー : ')'
> というエラーになったのでallocaを生で使ってます。

  ALLOCA_N()の使い方はあってるような気がするんですが…って
ruby.h を include してないじゃん。_WIN32 限定だから生でもいっか。

# しかしなんでトークンじゃなくて記号でしかメッセージを出さない
# かな。ALLOCA_N()にも type ってあるから悩んでしまった。

  それと SymInitialize() と SymEnumerateSymbols() に失敗したと
きの処理を若干修正してみました。SymUnloadModule() はしといた方
がいいですよね?

  てことで [ruby-dev:12642]からのパッチです。


--- dln.c-	Fri Mar 23 21:30:30 2001
+++ dln.c	Sat Mar 24 10:42:19 2001
@@ -1127,4 +1127,5 @@
 
 struct search_entry {
+    HMODULE module;
     const char* sym;
     char *name;
@@ -1136,6 +1137,9 @@
 {
     struct search_entry *const ent = arg;
-    if (FUNCNAME_MATCH(name, ent->sym)) {
-	ent->addr = (FARPROC)addr;
+    FARPROC proc;
+
+    if (FUNCNAME_MATCH(name, ent->sym) &&
+	(proc = GetProcAddress(name, ent->module))) {
+	ent->addr = proc;
 	strcpy(ent->name, name);
 	return FALSE;
@@ -1145,7 +1149,8 @@
 
 static FARPROC
-search_insensitively(const char *path, const char *sym, char *name)
+search_insensitively(const char *path, const char *sym, char *name, HMODULE module)
 {
     static HANDLE imagehlp;
+    static initialize_t initialize;
     static loadmodule_t loadmodule;
     static unloadmodule_t unloadmodule;
@@ -1155,6 +1160,4 @@
 
     if (!imagehlp) {
-	initialize_t initialize;
-
 	if (!(imagehlp = LoadLibraryExA("imagehlp.dll", NULL, LOAD_WITH_ALTERED_SEARCH_PATH)) ||
 	    !(initialize = (initialize_t)GetProcAddress(imagehlp, "SymInitialize")) ||
@@ -1171,8 +1174,11 @@
 	    errno = GetLastError();
 	    rb_warning("SymInitialize - %s", strerror(errno));
+	    initialize = NULL;
 	    return NULL;
 	}
     }
 
+    if (!initialize) return NULL;
+
     if (!(base = (*loadmodule)(0, 0, path, 0, 0, 0))) {
 	errno = GetLastError();
@@ -1181,11 +1187,12 @@
     }
 
-    ent.addr = 0;
+    ent.addr = NULL;
     ent.sym = sym;
     ent.name = name;
+    ent.module = module;
     if (!(*enumsyms)(0, base, symbols_i, &ent)) {
 	errno = GetLastError();
 	rb_warning("SymEnumerateSymbols(%s:%s) - %s", path, sym, strerror(errno));
-	return NULL;
+	ent.addr = NULL;
     }
 
@@ -1321,6 +1328,6 @@
 	/* try case insensitive search */
 	int len = strlen(buf) + 1/* including null terminator */;
-	char *name = (len > sizeof(buf) / 2) ? ALLOCA_N(char, len) : buf + len;
- 	if (!(init_fct = (void(*)())search_insensitively(winfile, buf, name))) {
+	char *name = (len > sizeof(buf) / 2) ? alloca(len) : buf + len;
+ 	if (!(init_fct = (void(*)())search_insensitively(winfile, buf, name, handle))) {
 	    goto failed2;
 	}


-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

In This Thread