mysql:3519
From: Kengo Jinno <Kengo Jinno <kengo@xxxxxxxxxx>>
Date: Mon, 09 Apr 2001 11:53:47 +0900
Subject: [mysql 03519] Re: Borland での挙動について
神野です。 Sun, 08 Apr 2001 20:33:44 +0900 ごろに <28C0C015C403BF.hirofujita8523@xxxxxxxxxx> の "[mysql 03515] Borland での挙動について" のメールで hirofujita8523 <hirofujita8523@xxxxxxxxxx> さんは書きました。 > 今回、Borland での挙動で困っています。 > 以下のソースを実行すると、main() 終了時にクラッシュしてしまいます。 問題の > mysql_data_seek(res, 0); // この行を抜けば正常に動作する ですが、 winclients-3.23.09a-sjis の mysql.h void STDCALL mysql_data_seek(MYSQL_RES *result, my_ulonglong offset); winclients-3_22_28_sjis の mysql.h void STDCALL mysql_data_seek(MYSQL_RES *result,unsigned int offset); と宣言されています。 第2引数の型が違うことに注意してください。 my_ulonglong は、 #if defined(NO_CLIENT_LONG_LONG) typedef unsigned long my_ulonglong; #elif defined (WIN32) typedef unsigned __int64 my_ulonglong; #else typedef unsigned long long my_ulonglong; #endif と定義されています。(どちらも同じ) 藤田さんのソースでは、 > #define NO_CLIENT_LONG_LONG > #include "mysql.h" なっているので、my_ulonglong は unsigned long 、 つまり、32bit符号なし整数です。 ■winclients-3.23.09a-sjis でクラッシュする理由 winclients-3.23.09a-sjis の mysql_data_seek() の第2引数は、 64bit整数だとして作成されているものと思われます。 STDCALL(Pascal呼び出し)ですから、スタックに積まれた引数は、 呼び出された側(mysql_data_seek())で解放します。 呼び出した側は第2引数として32bit(4byte)しか積んでないのに、 呼び出された側で64bit(8byte)解放すれば、マズいです。 ■winclients-3_22_28_sjis でクラッシュしない理由 winclients-3_22_28_sjis の mysql_data_seek() の第2引数は、 32bit符号なし整数です。(これは間違いない) 32bit(4byte)積んで32bit(4byte)解放しているのですから、 問題ありません。 ■winclients-3_22_28_sjis の mysql_num_fields() > (2).MySQL-3.22-Win32評価版(3.22.16-gamma)で、winclients-3_22_28_sjis > このうち、Borland では、(2) だけが動作します。 > しかし、mysql_num_fields() では、常に 0 しか返ってきません。 [mysql 03497]では、 > たぶん、サーバーがこれよりも新しく、 > ・フィールド数は他の方法で返す。 > ・MYSQL_RES::field_countにゼロが入っている。 > という実装になっているのではないかと思います。 という風に書きましたが、違うかもしれません。 MYSQL_RES型の定義でも、my_ulonglong型が使われています。 winclients-3_22_28_sjis の mysql.h typedef struct st_mysql_res { my_ulonglong row_count; unsigned int field_count, current_field; ... } MYSQL_RES; となっています。 libmysql側がmy_ulonglongを64bitとした構造体を返しているとして、 藤田さんのソース側でmy_ulonglongを32bitと想定して構造体に アクセスしたら、field_countの参照位置がズレる可能性があります。 row_countの上位32bitに相当する位置を参照していれば、常にゼロでも おかしくありません。 #ヘルプによると、bcc55のアライメントはデフォルトで4byte、 #VC5のアライメントはデフォルトで8byteです。 というわけで、 > どなたかこの症状の解消する術を教えていただけないでしょうか? my_ulonglong を64bit整数として定義してやればいいのでは ないでしょうか? bcc55のヘッダーファイルを見る限り、__int64 がサポートされて いるように思えるのですが・・・ -- 神野健吾 <kengo@xxxxxxxxxx>
3515 2001-04-08 20:33 [hirofujita8523 <hiro] Borland での挙動について -> 3519 2001-04-09 11:53 ┗[Kengo Jinno <kengo@x] 3537 2001-04-11 12:06 ┗[hirofujita8523 <hiro]