You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Ernst Mikkelsen (JIRA)" <ax...@ws.apache.org> on 2005/10/04 11:43:47 UTC
[jira] Created: (AXISCPP-847) Wrong definition of INVALID_SOCKET for non MS Windows platforms.
Wrong definition of INVALID_SOCKET for non MS Windows platforms.
----------------------------------------------------------------
Key: AXISCPP-847
URL: http://issues.apache.org/jira/browse/AXISCPP-847
Project: Axis-C++
Type: Bug
Components: Transport (axis3)
Versions: 1.5 Final
Environment: i5/OS (OS/400 iSeries) and *nix (Linux and others)
Reporter: Ernst Mikkelsen
Priority: Critical
In HTTPChannel.hpp and HTTPSSLChannel.hpp, INVALID_SOCKET is defined as 0 (zero). This causes a client using Axis C++ to fail consequently with a HTTPTransportException on the first connection attempt on the i5/OS, because 0 (zero) in fact is a valid socket descriptor on the i5/OS platform (as well as it is on other platforms such as Linux). This also means that real errors are not caught because -1 from the API is compared with to a 0 (zero).
To my knowledge, all platforms defines socket() to return either -1 or ~0 depending on whether socket() is implemented with a signed or unsigned return value.
My suggestion would be to change the following two files:
HTTPChannel.hpp line 56 in Axis C++ 1.5 Final
HTTPSSLChannel.hpp line 58 in Axis C++ 1.5 Final
from: const unsigned int INVALID_SOCKET = 0;
to: const unsigned int INVALID_SOCKET = ~0; // for unsigned socket() implementations
or: const int INVALID_SOCKET = -1; // for signed socket() implementations
As a workaround for this issue, I've tried to allocate a dummy socket in my client program before calling any of the Axis C++ methods, causing Axis C++ to succeed on the first connection attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: deserializing unsigned long via integer
Posted by Manohar K Chintala <cm...@in.ibm.com>.
Hi Nadir,
You can look at JIRA 788 for more details on this problem.
Regards
Manohar
Nadir Amra
<am...@us.ibm.com>
To
10/10/2005 08:45 "Apache AXIS C Developers List"
AM <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C deserializing unsigned long via
Developers List" integer
I have been testing out the code on OS/400 using the various XSD_xx tests
and I get failures on most of the numeric tests that have to do with long
long. In the AXIS code the UnsignedLong::deserializeUnsignedLong() calls
NonNegativeInteger::deserializeNonNegativeInteger() which calls the
Integer::deserializeInteger(), which uses a variable of type xsd__integer
to store the result as it attempts to convert the string to an integer.
My question is how can this be? An unsigned long long variable holds a
positive value that is greater than a long long variable. Am I missing
something here or is this a defect?
Nadir K. Amra
deserializing unsigned long via integer
Posted by Nadir Amra <am...@us.ibm.com>.
I have been testing out the code on OS/400 using the various XSD_xx tests
and I get failures on most of the numeric tests that have to do with long
long. In the AXIS code the UnsignedLong::deserializeUnsignedLong() calls
NonNegativeInteger::deserializeNonNegativeInteger() which calls the
Integer::deserializeInteger(), which uses a variable of type xsd__integer
to store the result as it attempts to convert the string to an integer.
My question is how can this be? An unsigned long long variable holds a
positive value that is greater than a long long variable. Am I missing
something here or is this a defect?
Nadir K. Amra
[jira] Commented: (AXISCPP-847) Wrong definition of INVALID_SOCKET for non MS Windows platforms.
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-847?page=comments#action_12331451 ]
nadir amra commented on AXISCPP-847:
------------------------------------
I will look into this further. An invalid socket should be -1. I think (please someone comment if not) that this is true for windows sockets so that chaning invalid socket constant to -1 should be ok.
The reason people do not have trouble with this on other platforms is because descriptors 0, 1, and 2 are reserved for stdin, stdout and stderr. On OS/400, if you kick off your program from within qshell, this will also be true. I assume on OS/400 you are kicking off the client program from CL command line.
This will be fixed.
> Wrong definition of INVALID_SOCKET for non MS Windows platforms.
> ----------------------------------------------------------------
>
> Key: AXISCPP-847
> URL: http://issues.apache.org/jira/browse/AXISCPP-847
> Project: Axis-C++
> Type: Bug
> Components: Transport (axis3)
> Versions: 1.5 Final
> Environment: i5/OS (OS/400 iSeries) and *nix (Linux and others)
> Reporter: Ernst Mikkelsen
> Priority: Critical
>
> In HTTPChannel.hpp and HTTPSSLChannel.hpp, INVALID_SOCKET is defined as 0 (zero). This causes a client using Axis C++ to fail consequently with a HTTPTransportException on the first connection attempt on the i5/OS, because 0 (zero) in fact is a valid socket descriptor on the i5/OS platform (as well as it is on other platforms such as Linux). This also means that real errors are not caught because -1 from the API is compared with to a 0 (zero).
> To my knowledge, all platforms defines socket() to return either -1 or ~0 depending on whether socket() is implemented with a signed or unsigned return value.
> My suggestion would be to change the following two files:
> HTTPChannel.hpp line 56 in Axis C++ 1.5 Final
> HTTPSSLChannel.hpp line 58 in Axis C++ 1.5 Final
> from: const unsigned int INVALID_SOCKET = 0;
> to: const unsigned int INVALID_SOCKET = ~0; // for unsigned socket() implementations
> or: const int INVALID_SOCKET = -1; // for signed socket() implementations
> As a workaround for this issue, I've tried to allocate a dummy socket in my client program before calling any of the Axis C++ methods, causing Axis C++ to succeed on the first connection attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-847) Wrong definition of INVALID_SOCKET for non MS Windows platforms.
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-847?page=all ]
nadir amra closed AXISCPP-847:
------------------------------
Fix Version: 1.6 Alpha
Resolution: Fixed
In UNIX implementations, socket descriptor is integer. So I made the following changes in HTTPChannel.hpp and HTTPSSLChannel.hpp:
const int INVALID_SOCKET = -1;
The above use to be unsigned with value of 0.
#ifdef WIN32
unsigned
#endif
int m_Sock; // Socket descriptor
> Wrong definition of INVALID_SOCKET for non MS Windows platforms.
> ----------------------------------------------------------------
>
> Key: AXISCPP-847
> URL: http://issues.apache.org/jira/browse/AXISCPP-847
> Project: Axis-C++
> Type: Bug
> Components: Transport (axis3)
> Versions: 1.5 Final
> Environment: i5/OS (OS/400 iSeries) and *nix (Linux and others)
> Reporter: Ernst Mikkelsen
> Assignee: nadir amra
> Priority: Critical
> Fix For: 1.6 Alpha
>
> In HTTPChannel.hpp and HTTPSSLChannel.hpp, INVALID_SOCKET is defined as 0 (zero). This causes a client using Axis C++ to fail consequently with a HTTPTransportException on the first connection attempt on the i5/OS, because 0 (zero) in fact is a valid socket descriptor on the i5/OS platform (as well as it is on other platforms such as Linux). This also means that real errors are not caught because -1 from the API is compared with to a 0 (zero).
> To my knowledge, all platforms defines socket() to return either -1 or ~0 depending on whether socket() is implemented with a signed or unsigned return value.
> My suggestion would be to change the following two files:
> HTTPChannel.hpp line 56 in Axis C++ 1.5 Final
> HTTPSSLChannel.hpp line 58 in Axis C++ 1.5 Final
> from: const unsigned int INVALID_SOCKET = 0;
> to: const unsigned int INVALID_SOCKET = ~0; // for unsigned socket() implementations
> or: const int INVALID_SOCKET = -1; // for signed socket() implementations
> As a workaround for this issue, I've tried to allocate a dummy socket in my client program before calling any of the Axis C++ methods, causing Axis C++ to succeed on the first connection attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-847) Wrong definition of INVALID_SOCKET for non MS Windows platforms.
Posted by "Ernst Mikkelsen (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-847?page=comments#action_12331695 ]
Ernst Mikkelsen commented on AXISCPP-847:
-----------------------------------------
Your assumption is correct. The problem occurs when the client is run from the CL command line.
Axis C++ does NOT define INVALID_SOCKET when WIN32 is defined, so the value can safely be changed to -1, as I see it.
I have found INVALID_SOCKET defined in the following header/source files (FYI):
./src/transport/axis2/Channel.h
./src/transport/axis3/HTTPChannel/HTTPChannel.hpp
./src/transport/axis3/HTTPSSLChannel/HTTPSSLChannel.hpp
./tests/utils/simple-server-client/cli.cpp
./tests/utils/simple-server-client/serv.cpp
> Wrong definition of INVALID_SOCKET for non MS Windows platforms.
> ----------------------------------------------------------------
>
> Key: AXISCPP-847
> URL: http://issues.apache.org/jira/browse/AXISCPP-847
> Project: Axis-C++
> Type: Bug
> Components: Transport (axis3)
> Versions: 1.5 Final
> Environment: i5/OS (OS/400 iSeries) and *nix (Linux and others)
> Reporter: Ernst Mikkelsen
> Assignee: nadir amra
> Priority: Critical
>
> In HTTPChannel.hpp and HTTPSSLChannel.hpp, INVALID_SOCKET is defined as 0 (zero). This causes a client using Axis C++ to fail consequently with a HTTPTransportException on the first connection attempt on the i5/OS, because 0 (zero) in fact is a valid socket descriptor on the i5/OS platform (as well as it is on other platforms such as Linux). This also means that real errors are not caught because -1 from the API is compared with to a 0 (zero).
> To my knowledge, all platforms defines socket() to return either -1 or ~0 depending on whether socket() is implemented with a signed or unsigned return value.
> My suggestion would be to change the following two files:
> HTTPChannel.hpp line 56 in Axis C++ 1.5 Final
> HTTPSSLChannel.hpp line 58 in Axis C++ 1.5 Final
> from: const unsigned int INVALID_SOCKET = 0;
> to: const unsigned int INVALID_SOCKET = ~0; // for unsigned socket() implementations
> or: const int INVALID_SOCKET = -1; // for signed socket() implementations
> As a workaround for this issue, I've tried to allocate a dummy socket in my client program before calling any of the Axis C++ methods, causing Axis C++ to succeed on the first connection attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AXISCPP-847) Wrong definition of INVALID_SOCKET for non MS Windows platforms.
Posted by "nadir amra (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-847?page=all ]
nadir amra reassigned AXISCPP-847:
----------------------------------
Assign To: nadir amra
> Wrong definition of INVALID_SOCKET for non MS Windows platforms.
> ----------------------------------------------------------------
>
> Key: AXISCPP-847
> URL: http://issues.apache.org/jira/browse/AXISCPP-847
> Project: Axis-C++
> Type: Bug
> Components: Transport (axis3)
> Versions: 1.5 Final
> Environment: i5/OS (OS/400 iSeries) and *nix (Linux and others)
> Reporter: Ernst Mikkelsen
> Assignee: nadir amra
> Priority: Critical
>
> In HTTPChannel.hpp and HTTPSSLChannel.hpp, INVALID_SOCKET is defined as 0 (zero). This causes a client using Axis C++ to fail consequently with a HTTPTransportException on the first connection attempt on the i5/OS, because 0 (zero) in fact is a valid socket descriptor on the i5/OS platform (as well as it is on other platforms such as Linux). This also means that real errors are not caught because -1 from the API is compared with to a 0 (zero).
> To my knowledge, all platforms defines socket() to return either -1 or ~0 depending on whether socket() is implemented with a signed or unsigned return value.
> My suggestion would be to change the following two files:
> HTTPChannel.hpp line 56 in Axis C++ 1.5 Final
> HTTPSSLChannel.hpp line 58 in Axis C++ 1.5 Final
> from: const unsigned int INVALID_SOCKET = 0;
> to: const unsigned int INVALID_SOCKET = ~0; // for unsigned socket() implementations
> or: const int INVALID_SOCKET = -1; // for signed socket() implementations
> As a workaround for this issue, I've tried to allocate a dummy socket in my client program before calling any of the Axis C++ methods, causing Axis C++ to succeed on the first connection attempt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira