[Maria-developers] SOCKET_SIZE_TYPE question on accept() call
Whild building mariadb on HP-UX, I ran into a problem with a call to accept(). The mariadb configure script uses MYSQL_TYPE_ACCEPT to determine if the third argument to accept should be type socklen_t or type int, and sets SOCKET_SIZE_TYPE accordingly, but in socket_accept (plugin/handler_socket/libhsclient/socket.cpp), the third argument to the accept call (addrlen_r) is hardcoded to be type socklen_t instead of using SOCKET_SIZE_TYPE. I think that the addrlen_r argument to socket_accept should be type SOCKET_SIZE_TYPE instead of socklent_t. I think this also means that the addrlen field in the socket_args structure (plugin/handler_socket/libhsclient/socket.hpp) should be type SOCKET_SIZE_TYPE instead of socklen_t. Does that sound right? Steve Ellcey sje@cup.hp.com
Hi, Steve! On Sep 22, Steve Ellcey wrote:
Whild building mariadb on HP-UX, I ran into a problem with a call to accept(). The mariadb configure script uses MYSQL_TYPE_ACCEPT to determine if the third argument to accept should be type socklen_t or type int, and sets SOCKET_SIZE_TYPE accordingly, but in socket_accept (plugin/handler_socket/libhsclient/socket.cpp), the third argument to the accept call (addrlen_r) is hardcoded to be type socklen_t instead of using SOCKET_SIZE_TYPE. I think that the addrlen_r argument to socket_accept should be type SOCKET_SIZE_TYPE instead of socklent_t. I think this also means that the addrlen field in the socket_args structure (plugin/handler_socket/libhsclient/socket.hpp) should be type SOCKET_SIZE_TYPE instead of socklen_t.
Does that sound right?
Yes, I suppose so. Can you just do this change (and other necessary changes if you find more portability issues), and send us a patch with all fixes together when MariaDB will finally compile? I will, of course, help you to decide how to fix every particular problem - just don't hesitate to ask :) I feel it may be faster and easier than waiting for us to fix every problem you find one by one. Regards, Sergei
On Fri, 2011-09-23 at 00:15 +0200, Sergei Golubchik wrote:
Can you just do this change (and other necessary changes if you find more portability issues), and send us a patch with all fixes together when MariaDB will finally compile? I will, of course, help you to decide how to fix every particular problem - just don't hesitate to ask :)
I feel it may be faster and easier than waiting for us to fix every problem you find one by one.
Regards, Sergei
I need to get some approvals from HP managers to send in patches as opposed to discussing things on the mailing list. I am working on getting that approval but I am not sure how long it will take. Also, is it your preference to get one large patch fixing multiple (unrelated) problems or do you prefer individual patches for individual problems? Steve Ellcey sje@cup.hp.com
Hi, Steve! On Sep 22, Steve Ellcey wrote:
On Fri, 2011-09-23 at 00:15 +0200, Sergei Golubchik wrote:
Can you just do this change (and other necessary changes if you find more portability issues), and send us a patch with all fixes together when MariaDB will finally compile? I will, of course, help you to decide how to fix every particular problem - just don't hesitate to ask :)
I need to get some approvals from HP managers to send in patches as opposed to discussing things on the mailing list. I am working on getting that approval but I am not sure how long it will take. Also, is it your preference to get one large patch fixing multiple (unrelated) problems or do you prefer individual patches for individual problems?
It doesn't matter. For simple issues like that I'll be able to see individual fixes in a one big patch, so you can do as you like. And of course it is not necessary for you to send patches or fix anything at all. I just thought that a procedure "you tell us about a problem, wait for an answer confirming the fix (if you need it), fix, go to the next problem" is faster for you than "you tell us, we fix, push, you pull the fix, repeat". But if you prefer me to do all the fixes, I can certainly do it. You choose :) Regards, Sergei
On Fri, 2011-09-23 at 08:30 +0200, Sergei Golubchik wrote:
It doesn't matter. For simple issues like that I'll be able to see individual fixes in a one big patch, so you can do as you like.
And of course it is not necessary for you to send patches or fix anything at all. I just thought that a procedure "you tell us about a problem, wait for an answer confirming the fix (if you need it), fix, go to the next problem" is faster for you than "you tell us, we fix, push, you pull the fix, repeat".
But if you prefer me to do all the fixes, I can certainly do it. You choose :)
Regards, Sergei
Well, until I get permission to send in patches it is probably better to let you do the fixes. I don't know how long it will take for my management to officially OK me sending in patches. I have been able to build Mariadb now on HP-UX 11.31 (but not pass all the tests), the only build issue that I ran into and haven't already brought up is with safe_strdup_root in include/my_sys.h. If I compile without optimization using the HP compiler I get an undefined reference to strdup_root when building 're'. The problem is that the function safe_strdup_root is included in objects that go into libmystrings.a (like ctype-simple.o). Even though there are no uses of this function in ctype-simple, and it is declared as static inline, the compiler is putting out a copy of the function. This function includes a call to strdup_root which is in mysys/my_alloc.c, but that object is not included in libmystrings.a so I get an error when linking 're'. My workaround for this was to move safe_strdup_root out of include/my_sys.h and into sql/sql_acl.cc since that is the only place it is used. Steve Ellcey sje@cup.hp.com
participants (2)
-
Sergei Golubchik -
Steve Ellcey