Click to See Complete Forum and Search --> : Windows SOCKET type question


ekhule
May 11th, 2010, 07:47 AM
Hello,

On http://www.sockets.com/winsock.htm it says:

Because the SOCKET type is unsigned, compiling existing source code from, for example, a UNIX environment may lead to compiler warnings about signed/unsigned data type mismatches.

This means, for example, that checking for errors when the socket() and accept() routines return should not be done by comparing the return value with -1, or seeing if the value is negative (both common, and legal, approaches in BSD). Instead, an application should use the manifest constant INVALID_SOCKET as defined in winsock.h. For example:

TYPICAL BSD STYLE:

s = socket(...);
if (s == -1) /* or s < 0 */
{...}

PREFERRED STYLE:

s = socket(...);
if (s == INVALID_SOCKET)
{...}


But, when I run a program on Windows and I do this line of code:

int test = INVALID_SCOKET;

test has the value or -1. According to http://www.sockets.com/winsock.htm#Accept accept() returns a SOCKET type, so how can SOCKET have a -1 value if it is an unsigned int?

Regards,
Ellay K.

hoxsiew
May 11th, 2010, 08:24 AM
Hello,

On http://www.sockets.com/winsock.htm it says:

Because the SOCKET type is unsigned, compiling existing source code from, for example, a UNIX environment may lead to compiler warnings about signed/unsigned data type mismatches.

This means, for example, that checking for errors when the socket() and accept() routines return should not be done by comparing the return value with -1, or seeing if the value is negative (both common, and legal, approaches in BSD). Instead, an application should use the manifest constant INVALID_SOCKET as defined in winsock.h. For example:

TYPICAL BSD STYLE:

s = socket(...);
if (s == -1) /* or s < 0 */
{...}

PREFERRED STYLE:

s = socket(...);
if (s == INVALID_SOCKET)
{...}


But, when I run a program on Windows and I do this line of code:

int test = INVALID_SCOKET;

test has the value or -1. According to http://www.sockets.com/winsock.htm#Accept accept() returns a SOCKET type, so how can SOCKET have a -1 value if it is an unsigned int?

Regards,
Ellay K.

Socket is unsigned in winsock. Use the macro SOCKET instead of int anywhere a socket is used:

SOCKET test = INVALID_SOCKET;

ekhule
May 11th, 2010, 09:19 AM
The questions i am asking is how can you assign a negative value (INVALID_SOCKET) to a unsigned int (SOCKET) ?

Regardless, if I use int instead of SOCKET the code works. Because INVALID_SOCKET is a -1 then this code works fine, because accept() returns -1 (like in unix):


int sock = accept(socket, (sockaddr*)(&addr), &addrLength);
if(sock < 0)
cout << "ERROR!" << endl;


So why on Windows would I even bother to change the int to SOCKET? If I keep it as int, it works on both Unix and Windows. Or am I missing something?

Regards,
Ellay K.

hoxsiew
May 11th, 2010, 09:58 AM
In theory, it should work fine. I don't know what MS's rationale was for deciding to deviate from Berkeley on this matter. I doubt you'd end up with 2 billion+ open sockets (the max for a signed int). But, if you use int, you'll get warnings about possible loss of data during conversion, and/or signed/unsigned mismatch comparisons unless you static cast every instance.

MikeAThon
May 11th, 2010, 05:51 PM
The hex pattern for INVALID_SOCKET is 0xFFFFFFFF. Casting to an unsigned integer will interpret this as decimal value 4,294,967,295, while casting to a signed integer will interpret this as decimal -1.

If you look at the header file, you will see the following define:
#define INVALID_SOCKET (SOCKET)(~0)
where the "~" is the bit-wise one's complement.

Does this help? (Maybe not, sorry.)

ekhule
May 12th, 2010, 06:33 AM
Yeah it makes perfect sense. So if you declare your return type as int instead of SOCKET it still works on windows if you compare the return value to see if it is less than 0. This makes Unix socket code work also on windows without modification. I dont know why they made such a big deal about using the SOCKET data type, when it's really not needed.

Regards,
Ellay K.