Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > How to determine the byte order of machine.

Reply
Thread Tools

How to determine the byte order of machine.

 
 
somenath
Guest
Posts: n/a
 
      02-20-2012
Hello All,
Is the following program can correctly determine the byte order of the
machine?
#include<stdio.h>
int main(void)
{
unsigned int x =1;
if ((x>>1) == 0)
printf("little-endian\n");
else
printf("Big-endian \n");
return 0;
}
In my opinion in case of little endian the 1 will be stored at the
last byte of the variable x. so if I shift it 1 byte the variable x
will have 0.But in case of big-endian 1 will be store at the right
most bye so right shifting by 1 should not be obtain 0. Is my
understanding correct?
I did not have access to big-endian machine. So i have not checked the
program in big-endian machine.

Thanks.
Somenath
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-20-2012
somenath <(E-Mail Removed)> writes:

> Hello All,
> Is the following program can correctly determine the byte order of the
> machine?


No. The output is independent of the way in which values are stored.

> #include<stdio.h>
> int main(void)
> {
> unsigned int x =1;
> if ((x>>1) == 0)
> printf("little-endian\n");
> else
> printf("Big-endian \n");
> return 0;
> }
> In my opinion in case of little endian the 1 will be stored at the
> last byte of the variable x. so if I shift it 1 byte the variable x
> will have 0.But in case of big-endian 1 will be store at the right
> most bye so right shifting by 1 should not be obtain 0. Is my
> understanding correct?


No. When x is unsigned (or signed and non-negative) x >> 1 is defined
to be the integer part of x/2. In effect, the shift operates on the
value bits in their value order.

> I did not have access to big-endian machine. So i have not checked the
> program in big-endian machine.


--
Ben.
 
Reply With Quote
 
 
 
 
somenath
Guest
Posts: n/a
 
      02-20-2012
On Feb 20, 4:49*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> somenath <(E-Mail Removed)> writes:
> > Hello All,
> > Is the following program can correctly determine the byte order of the
> > machine?

>
> No. *The output is independent of the way in which values are stored.
>
> > #include<stdio.h>
> > int main(void)
> > {
> > * * unsigned int x =1;
> > * * if ((x>>1) == 0)
> > printf("little-endian\n");
> > * * else
> > * *printf("Big-endian \n");
> > * * return 0;
> > }
> > In my opinion in case of little endian the 1 will be stored at the
> > last byte of the variable x. so if I shift it 1 byte the variable x
> > will have 0.But in case of big-endian 1 will *be store at the right
> > most bye so right shifting by 1 should not be obtain 0. Is my
> > understanding correct?

>
> No. *When x is unsigned (or signed and non-negative) x >> 1 is defined
> to be the integer part of x/2. *In effect, the shift operates on the
> value bits in their value order.
>

I did not get this point. could you please explain it in more detail
way?
 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      02-20-2012

"somenath" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> Hello All,
> Is the following program can correctly determine the byte order of the
> machine?
> #include<stdio.h>
> int main(void)
> {
> unsigned int x =1;
> if ((x>>1) == 0)
> printf("little-endian\n");
> else
> printf("Big-endian \n");
> return 0;
> }
> In my opinion in case of little endian the 1 will be stored at the
> last byte of the variable x. so if I shift it 1 byte the variable x
> will have 0.But in case of big-endian 1 will be store at the right
> most bye so right shifting by 1 should not be obtain 0. Is my
> understanding correct?
> I did not have access to big-endian machine. So i have not checked the
> program in big-endian machine.
>
> Thanks.
> Somenath


Hi,

x >> 1 is always x / 2, that does not depend on the byte order. Try e.g.
this instead (untested):

#include <stdio.h>
int main(void)
{
typedef unsigned char t_b[2];
union {
t_b b;
unsigned short s;
} u;
u.s = 1;
if (u.b[0] == 1)
// u.b[1] == 0
printf("little-endian\n");
else
// u.b[0] == 0
// u.b[1] == 1
printf("big-endian\n");
return 0;
}

Heiner


 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      02-20-2012

....
> x >> 1 is always x / 2,

I'm sorry - not always, but normally under the condition, that Ben wrote
....
 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      02-20-2012

"somenath" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
....
> No. When x is unsigned (or signed and non-negative) x >> 1 is defined
> to be the integer part of x/2. In effect, the shift operates on the
> value bits in their value order.
>

I did not get this point. could you please explain it in more detail
way?

An example:
0x04030201
on a big endian machine is
0x04 0x03 0x02 0x01,
on a little endian machine is
0x01 0x02 0x03 0x04

0x04030201 >> 1 is 0x02018100
That is
0x02 0x01 0x81 0x00
on a big endian machine and
0x00 0x81 0x01 0x02
on a little endian machine.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-20-2012
On 02/20/2012 06:35 AM, somenath wrote:
> Hello All,
> Is the following program can correctly determine the byte order of the
> machine?
> #include<stdio.h>
> int main(void)
> {
> unsigned int x =1;
> if ((x>>1) == 0)
> printf("little-endian\n");
> else
> printf("Big-endian \n");
> return 0;
> }


The expression E1 >> E2 has a value defined by the standard only for
non-negative x and non-negative values of E2 that are less than the
width of the type. When that is the case, the behavior defined by the
standard depends only upon the values of E1 and E2, and not on the way
that they are represented. Is is simply E1 / (2^E2); in this particular
case, that works out to 1/2, which is 0 according to C's rules for
integer division. The value of the result tells you nothing about the
byte order of unsigned int.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-20-2012
On 02/20/2012 07:11 AM, somenath wrote:
> On Feb 20, 4:49�pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>> somenath <(E-Mail Removed)> writes:
>>> Hello All,
>>> Is the following program can correctly determine the byte order of the
>>> machine?

>>
>> No. �The output is independent of the way in which values are stored.
>>
>>> #include<stdio.h>
>>> int main(void)
>>> {
>>> � � unsigned int x =1;
>>> � � if ((x>>1) == 0)
>>> printf("little-endian\n");
>>> � � else
>>> � �printf("Big-endian \n");
>>> � � return 0;
>>> }
>>> In my opinion in case of little endian the 1 will be stored at the
>>> last byte of the variable x. so if I shift it 1 byte the variable x
>>> will have 0.But in case of big-endian 1 will �be store at the right
>>> most bye so right shifting by 1 should not be obtain 0. Is my
>>> understanding correct?

>>
>> No. �When x is unsigned (or signed and non-negative) x >> 1 is defined
>> to be the integer part of x/2. �In effect, the shift operates on the
>> value bits in their value order.
>>

> I did not get this point. could you please explain it in more detail
> way?


Let's keep it simple, by considering an implementation where
CHAR_BIT==8, and UINT_MAX is 65535. The bits that make up an unsigned
int therefore represent the values 1, 2, 4, 8, 16, 32, 64, 128, 256,
512, 1024, 2048, 4096, 8192, 16384. Let's assume that the first 8 of
those bits are stored in the one byte, and the remaining 8 are stored in
the other one, without bothering to identify which order those bytes are
in. Whatever the value stored in x is, the expression x >> 1 produces a
result that would correspond to taking the value of the bit that
represents 2, and moving it into the bit that represents 1; moving the
value of the bit that represents 4, into the bit that represents 2; etc.

The interesting case is the bit representing 256, the value of which
must be moved into the bit which represents 128, which is in a different
byte. Here's the important point - it must be moved into that bit,
regardles of whether the byte containing that bit occurs before or after
the byte containing the bit representing 256 in memory. The "right" in
"right shift" refers only the to values of the bits, it has nothing to
do with the order of the bytes containing those bits in memory.

Another key point: the value of the bit that represents 1 simply
disappears - it does not get moved into the bit representing 16384 (that
would be called a rotation, rather than a shift), nor does it get moved
anywhere else. The bit representing 16384 simply gets set to 0.
--
James Kuyper
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      02-20-2012
somenath wrote:

> #include<stdio.h>
> int main(void)
> {
> unsigned int x =1;
> if ((x>>1) == 0)


1U >> 1 equals 0 on every C platform in the universe.

Consider

unsigned int x = 1;
unsigned char arr[sizeof x];
memcpy(arr, &x, sizeof x);
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-20-2012
On 2/20/2012 6:35 AM, somenath wrote:
> Hello All,
> Is the following program can correctly determine the byte order of the
> machine?


No.

> #include<stdio.h>
> int main(void)
> {
> unsigned int x =1;
> if ((x>>1) == 0)
> printf("little-endian\n");
> else
> printf("Big-endian \n");
> return 0;
> }


This code will print "little-endian\n" on all systems (barring
I/O errors and the like).

> In my opinion in case of little endian the 1 will be stored at the
> last byte of the variable x. so if I shift it 1 byte the variable x
> will have 0.But in case of big-endian 1 will be store at the right
> most bye so right shifting by 1 should not be obtain 0. Is my
> understanding correct?


No. For one thing, your explanations of little-endian and
big-endian seem rather confused; what do you mean, precisely, by
"last" and "right most?"

Even when the confusion is cleared up, you're missing the fact
that the `>>' operator (like most C operators) works with the values
of its operands, not with their representations. The `>>' operator
is most easily described in terms of a binary representation of its
first operand, and "right" shift suggests a certain way of writing
that representation -- but that doesn't mean the hardware actually
rolls bits around like so many tiny marbles. The bit that is discarded
by `>> 1' is the *least significant* bit, which in your example is
always 1 beforehand and 0 afterward.

> I did not have access to big-endian machine. So i have not checked the
> program in big-endian machine.


You should also be aware that "big-endian" and "little-endian"
do not exhaust all the possibilities. There have been "middle-endian"
machines, and "no-endian" CPU's are said to be fairly common among
digital signal processors and perhaps some supercomputers.

C requires that its unsigned integers behave "as if" written in
base 2 positional notation, with a 1's bit, 2's bit, 4's bit, and so
on. However, C says nothing at all about the arrangement of those
bits! For example, there is no rule requiring the 1's bit and the
2's bit to occupy the same byte of a multi-byte integer (it would
be perverse if they did not, but C tolerates perversity).

Your best bet is to write code that works with values, regardless
of how those values are represented. Ideally, you would not even
know how the machine represents eight hundred seventeen; you should
concern yourself with finding its factors or comparing it to nine
hundred twenty-six or whatever. It is occasionally necessary to
pierce the veil, but not very often.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Reading a signed byte in network byte order Robert Evans Ruby 7 11-15-2005 11:14 PM
Single byte addressable, multiple byte readout. Andreas VHDL 1 05-04-2004 01:49 PM
nuby: determine method passed and determine the receiver that received the method Pea, Botp Ruby 1 01-24-2004 07:51 PM
Appending byte[] to another byte[] array Bharat Bhushan Java 15 08-05-2003 07:52 PM



Advertisments