BorlandTalk.com

Steffen Rauh · Guest

Hi,

I'm working with BC++B6 Personal on Windows XP on 1,4 GHZ Pentium M with 256
MB DDR RAM. My project is to create classes for WinSock usage (a server
class and a client class). Now the problem I have:

typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
typedef UINT_PTR SOCKET;
#define INVALID_SOCKET (SOCKET)(~0)

class CSocketServer: public CSocketBase
{
[...]
protected:
SOCKET m_Socket;
[...]
};

CSocketServer::CSocketServer() : CSocketBase()
{
[...]
m_Socket = INVALID_SOCKET; // problem
[...]
}

The assignment of INVALID_SOCKET is not done. Before this line, m_Socket is
"0" and after this Line m_Socket still is "0". Assignments other than
INVALID_SOCKET (like 100, 300, 5 and so on) do not work too. m_Socket always
stays "0". The next section:

void CSocketServer::Listen(unsigned short Port)
{
[...]
SOCKET Socket;
try
{
Socket = CreateSocket();
BindSocket(Socket, Port);
ListenSocket(Socket);
}
catch (SocketExceptionClass* E)
{
DestroySocket(Socket);
throw E;
}
m_Socket = Socket; // problem
[...]
}

Socket works like always. The socket value is assigned, the socket is bound
and listened to, but on assigning Socket to m_Socket, again m_Socket stays
"0". Manually changing the value of m_Socket with the debugger always works.
But not with the source code itself.

I already tried to repoduce this behaviour within a simple example, but I
failed. On removing parts of the source code, it seems that the problem
jumps from one place to an other. One time I had a function call not taking
the parameter by value. The parameter simply stayed "0" no matter what the
value of the given variable was. On adding the removed source code again,
the problem is again at this m_Socket attribute.

Does anybody of you have an idea on how to trace such a problem? I'm not new
to programming neither to Borland products. But I never had such a behaviour
before. Perhaps a bug within the compiler? If anybody is interested in
testing the source code on its own machine, just send me an e-mail. The
whole source consists of 6 classes. But be prepared: it's work in progress
and still buggy.

Regards,
Steffen Rauh

Steffen Rauh · Guest

Perhaps I found the error. If I include:

#include "vcl.h"
#include "windows.h"
#include "winsock2.h"

instead of:

#include "winsock2.h"

the program seems to work correct again. Or the bug jumped to a place I'm
not able to find now.
Looking at the winsock2.h I noticed that this header file deals with
structure packing:

/*
* Ensure structures are packed consistently.
* Not necessary for WIN32, it is already packed >=4 and there are
* no structures in this header that have alignment requirement
* higher than 4.
* For WIN64 we do not have compatibility requirement because it is
* not possible to mix 32/16 bit code with 64 bit code in the same
* process.
*/

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

Could it be possible, that the bug was created because of wrong data
structure packing? Are there any known influences or dependencies of "vcl.h"
and "windows.h" on "winsock2.h"?

Regards,
Steffen Rauh