At 10:30 AM -0500 10/24/99, Chad Miller wrote:
>> Chad Miller writes:
>> mysql_options(&mysql, MYSQL_OPT_CONNECT_TIMEOUT, "10");
>> The connect() times-out in about 10 minutes (plus or minus three!) [...]
>On Sun, Oct 24, 1999 at 02:27:28PM +0300, sinisa@stripped wrote:
>> You have not stated in your e-mail, nor in earlier what is exactly
>> your problem.
>Thought I had said enough. The mysql_real_connect() (abbr. as just
>"connect()" in my previous description) timed out in (on mean,) ten
>minutes. The default timeout value didn't make a difference in the
>I tracked it down to two exclusive problems:
>The above options() syntax is incorrect. The function prototype in the
>online manual types the third argument to char*, when it  is actually
>int*, when using MYSQL_OPT_CONNECT_TIMEOUT. The prototype suggested
>(ambiguously) that the timeout should be a null-terminated array of chars.
I must admit that I find it somewhat odd that you're taking exception
to imprecision in a function prototype when you report problems in
terms of made up names for the functions (connect(), options()) rather
than the actual names of the functions. Is that supposed to make your
descriptions clearer in some sense? It certainly didn't for me.
Also, saying that the prototype is actually int* is puzzling. I looked
in the mysql.h include file and the libmysql.c source file and they both
say char*. Are you saying that the third argument *should* be int*, or what?
You may have a point in suggesting that this should be void* rather than
char*, but in any case, the description of the function in the manual
points out that for MYSQL_OPT_CONNECT_TIMEOUT, the argument should be
unsigned int *. Why would you expect it to be a null-terminated array
>Secondly, and the _real_ reason that timeouts (even the default 20)
>didn't work appears to be that despite the configure script finding
>"sys/un.h", the #define was never included in client/libmysql.c , and the
>connect2() was never used, but the later connect() (which doesn't
>timeout the same way) was.
>I unpacked the sources again, and can't reproduce what caused the missing
>HAVE_SYS_UN_H , so I can't explain it; the detection code in the
>configure.in is correct. I'm not too fond of indeterminanacy in my code.
>In any case, I have working code and no patch to send, except the sugges-
>tion to change the manual to read something like ``void *'' in the third
>argument of options()' prototype, and explain why void and not char or int.
Paul DuBois, paul@stripped