Re: Byte ordering and array access

stathis gotsis wrote:

"Benjamin M. Stocks" <stocksb@xxxxxxxx> wrote in message
news:1139413176.945111.100840@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello all,
I've heard differing opinions on this and would like a definitive
answer on this once and for all. If I have an array of 4 1-byte
values where index 0 is the least signficant byte of a 4-byte value.
Can I use the arithmatic shift operators to hide the endian-ness of
the underlying processor when assembling a native 4-byte value like
follows:

unsigned int integerValue;
unsigned char byteArray[4];

/* byteArray is populated elsewhere, least signficant byte in index
0, guaranteed */

integerValue = (unsigned int)byteArray[0] |
((unsigned int)byteArray[1] << 8) |
((unsigned int)byteArray[2] << 16) |
((unsigned int)byteArray[3] << 24);

So if byteArray[0] was 0x78, byteArray[1] was 0x56, byteArray[2] was
0x34 and byteArray[3] was 0x12 then would integerValue be 0x12345678
no matter the endian-ness of the processor?

May i ask a question on this? Can the endian-ness of the processor
affect the "<<" shifting direction? From the replies i assume it does.
I need an example where this operator shifts to the right.

No, it does not affect shift "direction". It may help if you think of
shifts as repeated integer divisions/multiplications by 2 (that's how
Standard defines them -- they work on /values/ not representations).
Endianness only affect how values are stored in memory (their bit
representation, if you will). IOW, before performing the shift, C
program reads operand's representation, figures out the /value/,
performs shifting (i.e. division/multiplication), and if required
converts value back to representation, and stores it back.

I don't think you can construct the representation/endinanness
combination that will "reverse" shifts. Or, I'm not at my creative best
at the moment (a distinct possibility -- it's Friday evening, I should
be in a pub).

--
BR, Vladimir

Every improvement in communication makes the bore more terrible.
-- Frank Moore Colby

.

Relevant Pages

  • Re: Dynamically resizing a buffer
    ... Because you consider shift an appropriate method of halving a number. ... you would have to consider unsigned and signed as different because right shifting negative numbers is not guaranteed to act as division. ... It does, however, show that you are thinking of manipulating the representation rather than the fundamental concept. ... Exponential is also a natural growth curve, if you don't believe me check how populations grow in nature, for at least some it is exponential until a crash. ...
    (comp.lang.c)
  • Re: Dynamically resizing a buffer
    ... Shift is for moving bits, ... Otherwise shift would work on floating point and would have behaviour defined by the C standard for negative numbers (it leaves it for the implementation to define the result of right shifting a negative number). ... Binary is not the only representation for numbers, it just happens to be the current vogue in computing. ... Exponential is also a natural growth curve, if you don't believe me check how populations grow in nature, for at least some it is exponential until a crash. ...
    (comp.lang.c)
  • Re: Arithmetic shift operation in C
    ... >>> Shift operations in C are only portable, and properly defined, on ... > That's tricky, a shift works at the representation level, and in addition ... >> shift of a signed integer which only involves representable non-negative ... > what happens at the representation level. ...
    (comp.lang.c)
  • Re: Byte ordering and array access
    ... it's bit representation. ... In short, Standard specifies that, if the right operand is negative (or ... Bitwise shift operators ... an unsigned type or if E1 has a signed type and a nonnegative value, ...
    (comp.lang.c)
  • Re: Arithmetic shift operation in C
    ... > That's tricky, a shift works at the representation level, and in addition ... an `int' representation with padding bits: ... into the middle padding position and get "swallowed" there. ...
    (comp.lang.c)