Re: Byte ordering and array access


"Robin Haigh" <ecl6rsh@xxxxxxxxxxx> wrote in message
news:dsnste$kon$1@xxxxxxxxxxxxxxxxxxxxxx

You need two different orderings before you can discuss how they relate to
each other.

When you store a 16-bit unsigned integer value into 2 bytes of
byte-addressable memory (and this didn't arise before byte-addressing), by
common custom and convention (but no absolute rule) you encode it
base-256,
i.e. the byte values you store will be x/256 and x%256.

On that assumption, you now have an ordering by significance -- one byte
is
the "big" byte -- and also an ordering by memory address, so you can talk
about which byte (by significance) is the low-address byte, i.e.
endianness.


Yes, i was curious if there are other encodings in real systems, other than
this common one, leading to other possibilities for endianness.

With the bits involved in bitwise operations, you have an ordering by
significance, but only that. There's no low-address end or left-hand end
or
any other positional description. You can certainly access the LSB, but
every way of doing so refers to it by significance, essentially. So you
can't talk about relative bit-ordering, because you can't see anything for
it to be relative to.

So, i come to the conclusion that shifting operations hide endianness from
the programmer. Maybe one could reveal endianness this way?

#include <stdio.h>

int main(void)
{
int i=0;
unsigned int a = 0xabcdabcd;
unsigned char *b;
b=(unsigned char *)&a;

while (i<sizeof(a))
{
printf("%d byte: %x\n",i+1,b[i]);
i++;
}

return 0;
}

Of course this changes when you serialise the bits in a byte onto a serial
communications line. Then, you do have another ordering, so the hardware
does have to agree on the bit-endianness and reassemble the byte values as
transmitted. But, unlike the cpu vendors, the bus and network vendors (by
some miracle) do have this all sorted out, and we don't actually get to
see
bit-swapped bytes, so we treat it as a non-issue. The danger that you
fear
was potentially real, but has been averted.
The terms "left-shift" and "right-shift" are motivated by the fact that in
America and many other countries, when numbers are written down in
place-value notation, we write the big end on the left. If numbers were
normally written the other way round, e.g. 000,000,1 for a million, the
names would have been reversed. This hasn't got anything to do with cpu
architecture.

Yes, that is clear to me now.


.

Relevant Pages

  • Re: MD5 algorithm
    ... Note the endianness of the 64 bit message length field, ... It also contains a few more Test Vectors than the Wikipedia article. ... So far I just padded my int[] ... words in normal big-endian order. ...
    (comp.lang.java.programmer)
  • Re: [PATCH 4/6] udf: convert udf_stamp_to_time and udf_time_to_stamp to use timestamps
    ... so let these functions handle endianness ... internally and don't clutter code with conversions ... int yday; ...
    (Linux-Kernel)
  • Re: Endian Independence
    ... from one endianness to another (more specifically from big-endian to ... small or vice versa). ... preserve the sign and treat the number as an unsigned int or am i ...
    (comp.lang.c)
  • Re: memcpy() and endianness
    ... discussions is what endianness _is_. ... it is the relationship between the CPU ... architecture/platform it's run on, ALWAYS do the ... memory_ on all architectures where the sizeof (int) is four, ...
    (comp.lang.c)