Using winsock send() & recv() with integers or floats
Author
Could anyone explain why the winsock functions send() and recv() require a char * buffer as their second parameter? Is there some way to avoid this, and if not, how do you deal with it? I''ve been unable to cast the integer or floating point values I''d like to send and recieve to char * buffers.
Thanks
I believe it was because c doesnt have a byte..or they just prefer char..
because char is 1 byte..int is 4 bytes..
4 chars is 1 int.
buffer[4] = an int so thats what you send over
then when you get it back you cast it to an integer.
eg:
buffer[4];
recv(&buffer)
int var = (int)buffer;
I think hehe
because char is 1 byte..int is 4 bytes..
4 chars is 1 int.
buffer[4] = an int so thats what you send over
then when you get it back you cast it to an integer.
eg:
buffer[4];
recv(&buffer)
int var = (int)buffer;
I think hehe
Ouch - its dodgy as hell though - unless your reciever unpacks the chars with the same endien-ness (but I''m guessing your targets are the same as your source).
Because, TCP based on byte-stream.
So transmit unit is a byte.
Commonly, char represents a byte.
But available, send(socketValue, (char*)&theInt, sizeof(theInt), 0);
[edited by - veruna2k on May 28, 2003 5:57:29 AM]
So transmit unit is a byte.
Commonly, char represents a byte.
But available, send(socketValue, (char*)&theInt, sizeof(theInt), 0);
[edited by - veruna2k on May 28, 2003 5:57:29 AM]
It''s true that a char is always a basic machine unit (i.e. a byte), but it''s still weird. After all, a void pointer could do the job just fine - better even, because you don''t need those weird casts.
cu,
Prefect
cu,
Prefect
> Could anyone explain why the winsock functions send()
> and recv() require a char * buffer as their second
> parameter?
The BSD socket API was devised by under the 'Old C' language rules back in 1983 (i.e. there was no 'void' type back then) and I'd bet the university regents never bothered keeping it up to date with newer ANSI-C standard when it distributed the BSD unix license. The rest is history as they say...
-cb
PS: I've checked sbrk() and brk() and they differ. BSD-decendents use 'char' while the AT&T descendents use 'void' ! What are regents for...
[edited by - cbenoi1 on May 28, 2003 5:29:50 PM]
> and recv() require a char * buffer as their second
> parameter?
The BSD socket API was devised by under the 'Old C' language rules back in 1983 (i.e. there was no 'void' type back then) and I'd bet the university regents never bothered keeping it up to date with newer ANSI-C standard when it distributed the BSD unix license. The rest is history as they say...
-cb
PS: I've checked sbrk() and brk() and they differ. BSD-decendents use 'char' while the AT&T descendents use 'void' ! What are regents for...
[edited by - cbenoi1 on May 28, 2003 5:29:50 PM]
use a message struct
typedef struct sMsg
{
char Type;
char Data[512];
}
use Type to get data out of Data, which is 512 bytes big.
.lick
typedef struct sMsg
{
char Type;
char Data[512];
}
use Type to get data out of Data, which is 512 bytes big.
.lick
i suppose this depends on the complier and compiler options, but if your structure is not properly aligned the compiler will pack it in order to align it.
for example:
// a non-aligned structure
typedef struct {
char oneByte;
int someInt;
} mystruct;
mystruct notAligned;
char buffer[8] = {1, 2, 3, 5, 0, 0, 0, 0};
memcpy(¬Aligned, &buffer, sizeof(mystruct));
u''d think that this would set the 2, 3, and 5 bytes as the first three bytes of the int, but it doesn''t. if u are using a debugger such as msvc++, you can look and see what happens as you step over the memcpy call. alternately u can just set an integer to sizeof(mystruct) and see if it equals, in this case, 5. it will probably equal 8.
of course, this isn''t a problem unless you''re recieving directly into structs.
for example:
// a non-aligned structure
typedef struct {
char oneByte;
int someInt;
} mystruct;
mystruct notAligned;
char buffer[8] = {1, 2, 3, 5, 0, 0, 0, 0};
memcpy(¬Aligned, &buffer, sizeof(mystruct));
u''d think that this would set the 2, 3, and 5 bytes as the first three bytes of the int, but it doesn''t. if u are using a debugger such as msvc++, you can look and see what happens as you step over the memcpy call. alternately u can just set an integer to sizeof(mystruct) and see if it equals, in this case, 5. it will probably equal 8.
of course, this isn''t a problem unless you''re recieving directly into structs.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
