[前][次][番号順一覧][スレッド一覧]

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]