Re: A portable code to create a 4-bytes Big Endian twos complementsigned integer in a misaligned add

Discussion in 'C Programming' started by Jorgen Grahn, Mar 17, 2011.

  1. Jorgen Grahn

    Jorgen Grahn Guest

    On Thu, 2011-03-17, pozz wrote:
    ....
    > Now I need to create a data packet (to send over a network) with the
    > following syntax:
    > - Byte 1: SOP (Start of Packet)
    > - Byte 2-3-4-5: value in Big Endian twos complement
    > - Byte 6: EOP (End of Packet)
    >
    > How can I do that in the most portable way, assuming only the same
    > method to store negative numbers in memory (twos complement)?
    >
    > One solution could be:
    > unsigned char data[6] = { SOP, 0, 0, 0, 0, EOP };
    > data[1] = (x >> 24) & 0xFF;
    > data[2] = (x >> 16) & 0xFF;
    > data[3] = (x >> 8) & 0xFF;
    > data[4] = (x >> 0) & 0xFF;
    > This code should work with Big- or Little-Endian implementations.


    Apart from the signedness of 'x' (I've never had to serialize signed
    numbers) that's what I would do.

    > Or is it better to use htons()/htonl()?
    > int32_t tmp;
    > unsigned char data[6] = { SOP, 0, 0, 0, 0, EOP };
    > tmp = htonl(x);
    > memcpy (&data[1], &tmp, 4);


    No. I don't like htonl() and friends: they introduce variables which
    aren't really integers ('tmp' above) and they reduce type safety (the
    memcpy above). And you need little-endian hardware to find the
    bugs!

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 17, 2011
    #1
    1. Advertising

  2. Jorgen Grahn

    Sebastian Guest

    On 17 Mrz., 16:58, pozz wrote:
    >
    > I'm sorry, but I couldn't understand what's the problem
    > with the signedness of 'x'.


    The C ISO standard doesn't require negative numbers to be represented
    in 2's complement. So, you can't rely on a specific bit pattern for
    negative numbers. But if you convert a signed int to an unsigned int
    you *can* rely in the resulting bit pattern and this bit pattern will
    be a 2's complement representation of the original signed value. This
    follows from the conversion rule that says the source value is
    congruent to the target value modulo pow(2,N) where N is the number of
    bits in the unsigned target type.

    int i;
    unsigned j;
    i = -3; // 100...0011 is *one possible* binary representation of i
    j = i; // 111...1110 is a guaranteed binary representation of j

    > I think I can safely assume int32_t is defined on C implementations
    > where I'll want to compile my code.


    If you can rely on the existence of int32_t then you can also rely on
    2's complement for the representation of negative numbers. IIRC, C99
    makes the guarantee that if typedefs for exact-width integer types are
    present in stdint.h, that these integer types make use of 2's
    complement for representing the values.

    SG
    Sebastian, Mar 17, 2011
    #2
    1. Advertising

  3. Jorgen Grahn

    Guest

    On 17 Mrz., 17:33, Sebastian <> wrote:
    >   int i;
    >   unsigned j;
    >   i = -3;  // 100...0011 is *one possible* binary representation ofi
    >   j = i;   // 111...1110 is a guaranteed binary representation of j


    I hope you mean 111...1101.

    --
    DPS
    , Mar 25, 2011
    #3
    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. hicham
    Replies:
    2
    Views:
    9,005
    dxcoder
    Jul 2, 2003
  2. Replies:
    5
    Views:
    333
    Stephen Sprunk
    Aug 31, 2006
  3. James Kuyper
    Replies:
    3
    Views:
    335
    James Kuyper
    Mar 19, 2011
  4. Spiros Bousbouras
    Replies:
    6
    Views:
    410
    Ben Bacarisse
    Mar 18, 2011
  5. Tim Rentsch
    Replies:
    0
    Views:
    456
    Tim Rentsch
    Mar 19, 2011
Loading...

Share This Page