[
https://issues.apache.org/jira/browse/IGNITE-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kalashnikov updated IGNITE-7515:
---------------------------------------
Description:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2
flavors.
One returns error code and another character string.
Current code seems to expect the XSI version, which returns an int.
But if we happen to compile against the other version, the error messages will
be missing from the diagnostic messages and logs.
The man page for {{strerror_r()}} provides the macros to distinguish the two
versions, but that is not very portable.
I suggest that we create a test in {{configure.ac}} to define specific macro to
tell what {{strerror_r()}} variant we have.
AC_CACHE_CHECK(
[for support of strerror_r that returns int],
[odbc_have_int_strerror_r],
[AC_RUN_IFELSE(
[AC_LANG_SOURCE[
#include <string.h>
#include <errno.h>
int main(int argc, char** argv)
{
char buf[256] = \\{0};
int ret = strerror_r(ENOMEM, buf, sizeof(buf));
return ret;
}
]],
[odbc_have_int_strerror_r=yes],
[odbc_have_int_strerror_r=no])])
if test "$odbc_have_int_strerror_r" = "yes"; then
AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int
strerror_r])
was:
Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in 2
flavors.
One returns error code and another character string.
Current code seems to expect the XSI version, which returns an int.
But if we happen to compile against the other version, the error messages will
be missing from the diagnostic messages and logs.
The man page for {{strerror_r()}} provides the macros to distinguish the two
versions, but that is not very portable.
I suggest that we create a test in {{configure.ac}} to define specific macro to
tell what {{strerror_r()}} variant we have.
AC_CACHE_CHECK(
[for support of strerror_r that returns int],
[odbc_have_int_strerror_r],
[AC_RUN_IFELSE(
[AC_LANG_SOURCE[
#include <string.h>
#include <errno.h>
int main(int argc, char** argv) {
char buf[256] = \{0};
int ret = strerror_r(ENOMEM, buf, sizeof(buf));
return ret;
}
]],
[odbc_have_int_strerror_r=yes],
[odbc_have_int_strerror_r=no])])
if test "$odbc_have_int_strerror_r" = "yes"; then
AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int
strerror_r])
> ODBC: Socket error messages may be missing on linux
> ---------------------------------------------------
>
> Key: IGNITE-7515
> URL: https://issues.apache.org/jira/browse/IGNITE-7515
> Project: Ignite
> Issue Type: Bug
> Components: odbc
> Affects Versions: 2.3
> Reporter: Sergey Kalashnikov
> Priority: Minor
>
> Function {{GetSocketErrorMessage()}} uses {{strerror_r()}}, which can come in
> 2 flavors.
> One returns error code and another character string.
> Current code seems to expect the XSI version, which returns an int.
> But if we happen to compile against the other version, the error messages
> will be missing from the diagnostic messages and logs.
> The man page for {{strerror_r()}} provides the macros to distinguish the two
> versions, but that is not very portable.
> I suggest that we create a test in {{configure.ac}} to define specific macro
> to tell what {{strerror_r()}} variant we have.
>
> AC_CACHE_CHECK(
> [for support of strerror_r that returns int],
> [odbc_have_int_strerror_r],
> [AC_RUN_IFELSE(
> [AC_LANG_SOURCE[
> #include <string.h>
> #include <errno.h>
> int main(int argc, char** argv)
> {
> char buf[256] = \\{0};
> int ret = strerror_r(ENOMEM, buf, sizeof(buf));
> return ret;
> }
> ]],
> [odbc_have_int_strerror_r=yes],
> [odbc_have_int_strerror_r=no])])
> if test "$odbc_have_int_strerror_r" = "yes"; then
> AC_DEFINE([HAVE_INT_STRERROR_R], [1], [1 in case the runtime provides int
> strerror_r])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
