char to int conversion

[aki]

i am receiving a packet from network and it contains many fields ,
starting from code, idetifier
...., i want to read the code field which is of size 1 byte.
checking the code value i need to go ahed of my logic...

i am receving packet in buffer variable like.

function(*buffer)
{
char*p =(ntohs)buffer;// changin bufferfrom network byte order to
host order


switch(*p) // will it decode to some integer value...if not then how
can i do it...

case 1:
--
break;
case 2:
---
--
}

can i do type conversion..?

any comments are welcome...

thanks
akhi

 

[Ian Collins]

i am receiving a packet from network and it contains many fields ,
starting from code, idetifier
...., i want to read the code field which is of size 1 byte.
checking the code value i need to go ahed of my logic...

i am receving packet in buffer variable like.

function(*buffer)
{
char*p =(ntohs)buffer;// changin bufferfrom network byte order to
host order

That's garbage, post the real code.

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

i am receiving a packet from network and it contains many fields ,
starting from code, idetifier
..., i want to read the code field which is of size 1 byte.
checking the code value i need to go ahed of my logic...

i am receving packet in buffer variable like.

function(*buffer)

function(char* buffer)

{
char*p =(ntohs)buffer;// changin bufferfrom network byte order to
host order

char* p = ntohs(*buffer)

It's a function-call, but it operates on 16-bit shorts so you have to
dereference the pointer in the call and make sure that the buffer is
at least 16 bits large. Notice that if you only operate on chard/bytes
then you don't need ntohs() since there's only one way to represent a
byte on both the network and on the machine.

switch(*p) // will it decode to some integer value...if not then how
can i do it...

case 1:

Have you tried the above? It seem to be OK to me but I'm not totally
sure. Since p points to a char and a char can be promoted to an int I
think the above should work, but if you want to be sure you can always
cast the char to an int first and perform the switch over the int.

 

[James Kanze]

function(char* buffer)

char* p = ntohs(*buffer)

It's a function-call, but it operates on 16-bit shorts so you have to
dereference the pointer in the call and make sure that the buffer is
at least 16 bits large.

Also, in practice, I can't imagine it being much used today. It
represents an early attempt to manage different representations
of the same data type, but it doesn't really solve the problem,
and we know of better solutions today.

Notice that if you only operate on chard/bytes
then you don't need ntohs() since there's only one way to represent a
byte on both the network and on the machine.

Sure there are---at least one system sold today has nine bit
one's complement bytes, for example. And the problem isn't just
representing a byte. No one really cares about "bytes"; what's
interesting is what the byte is representing, and how it is
encoded.

Network protocols transfer "octets" (most, at least---although
in the past, I worked with one that used sextets---six bit
bytes). Presumably, from what he is saying, his code field is
encoded on a single octet. The question is, of course, how is
it encoded? Without knowing that, there's not much we can say.
If it's encoded as a small integral value, then the normal
integral promotions in C++ will suffice to access it, at least
if the value is guaranteed positive (less than 128, and greater
than or equal to 0). If it's encoded as an ASCII character,
then he can probably access it directly as well, as long as his
code doesn't have to run on a mainframe. (IBM mainframes still
use EBCDIC, and I have no idea what Unisys mainframes use, with
their 9 bit bytes.) Even on a mainframe, he can still access
the data as a character as long as he explicitly compares it to
the ASCII encoding, rather than a character constant (i.e. 0x30,
rather than '0'---which is 0xF0 on an IBM mainframe).

 

[Ian Collins]

Also, in practice, I can't imagine it being much used today. It
represents an early attempt to manage different representations
of the same data type, but it doesn't really solve the problem,
and we know of better solutions today.

From what I have seen, this family of ordering functions are still
widely used. They have been updated (at least in POSIX) to use the C99
fixed width types. So ntohs is now

uint16_t ntohs(uint16_t);