char to int conversion

Discussion in 'C++' started by aki, Apr 23, 2007.

  1. aki

    aki Guest

    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
    aki, Apr 23, 2007
    #1
    1. Advertising

  2. aki

    Ian Collins Guest

    aki wrote:
    > 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.

    --
    Ian Collins.
    Ian Collins, Apr 23, 2007
    #2
    1. Advertising

  3. On 23 Apr, 11:36, aki <> wrote:
    > 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:
    > --
    > break;
    > case 2:
    > ---
    > --
    >
    > }


    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.

    --
    Erik Wikström
    =?iso-8859-1?q?Erik_Wikstr=F6m?=, Apr 23, 2007
    #3
  4. aki

    James Kanze Guest

    On Apr 23, 12:02 pm, Erik Wikström <> wrote:
    > On 23 Apr, 11:36, aki <> wrote:


    > > 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.


    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).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Apr 24, 2007
    #4
  5. aki

    Ian Collins Guest

    James Kanze wrote:
    > On Apr 23, 12:02 pm, Erik Wikström <> wrote:
    >
    >>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.
    >

    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);

    --
    Ian Collins.
    Ian Collins, Apr 24, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Schnoffos
    Replies:
    2
    Views:
    1,209
    Martien Verbruggen
    Jun 27, 2003
  2. trey

    newbie: char* int and char *int

    trey, Sep 10, 2003, in forum: C Programming
    Replies:
    7
    Views:
    403
    Irrwahn Grausewitz
    Sep 10, 2003
  3. Hal Styli
    Replies:
    14
    Views:
    1,629
    Old Wolf
    Jan 20, 2004
  4. lovecreatesbeauty
    Replies:
    1
    Views:
    1,043
    Ian Collins
    May 9, 2006
  5. gert
    Replies:
    20
    Views:
    1,157
Loading...

Share This Page