Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > About little big endian in C

Reply
Thread Tools

About little big endian in C

 
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
Hello,

I am wondering when does the little or big endian affects the code ?
In which cases should I check if a machine uses Little or Big Endian?

- For example does it affect bitwise operations ? eg. x >> 10

- Does it affect operations like accessing memory with a (char *) ?
(in order to access individual bytes)

Any extra info/references is welcome

Thanks for your time and sorry for my (bad) english

 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      10-08-2007
On Oct 8, 11:36 am, charp...@yahoo.com wrote:
> Hello,
>
> I am wondering when does the little or big endian affects the code ?
> In which cases should I check if a machine uses Little or Big Endian?
>
> - For example does it affect bitwise operations ? eg. x >> 10
>
> - Does it affect operations like accessing memory with a (char *) ?
> (in order to access individual bytes)
>
> Any extra info/references is welcome
>
> Thanks for your time and sorry for my (bad) english


When big-endian verses little endian matters is when you have to
exchange information between computers.
<OT>
Normally, if you use TCP/IP to communicate, you will use ntoh() and
hton() to swap things
</OT>
There is a related C-FAQ:

20.9: How can I determine whether a machine's byte order is big-
endian
or little-endian?

A: One way is to use a pointer:

int x = 1;
if(*(char *)&x == 1)
printf("little-endian\n");
else printf("big-endian\n");

It's also possible to use a union.

See also question 10.16.

References: H&S Sec. 6.1.2 pp. 163-4.

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      10-08-2007
said:

> Hello,
>
> I am wondering when does the little or big endian affects the code ?


Never, if you're careful and lucky.

> In which cases should I check if a machine uses Little or Big Endian?


If you stick to standard C and only ever have to process files that you
have yourself produced on a single implementation, the answer is - as near
as makes no odds - never.

Normally it starts to matter when you're reading integers from a binary
file (or writing them /to/ a binary file).

> - For example does it affect bitwise operations ? eg. x >> 10


No, this operates purely on the value of x, not its representation.

>
> - Does it affect operations like accessing memory with a (char *) ?
> (in order to access individual bytes)


To access individual bytes, use an unsigned char *.

"Big endian" means that the most significant values come first in the
underlying representation. A good example is prices in a shop: when we see
39.99 on a pair of jeans, we know that it's about 40 currency units, not
almost a hundred currency units. "Little endian" means that the least
significant values come first - and I suppose the obvious example would be
UK date format: day/month/year.

So if you do something like this:

int x = 1;
unsigned char *p = (unsigned char *)&x;
printf("%d\n", *p);

it is likely to print 1 on a little-endian system, but 0 on a big-endian
system (provided sizeof(int) is at least 2, which isn't actually
guaranteed), whereas if you had written:

int x = 1;
unsigned char *p = (unsigned char *)&x;
p += (sizeof x) - 1;
printf("%d\n", *p);

it is likely to print 0 on a little-endian system, but 1 on a big-endian
system.

Generally, such code is best avoided. If you need to know whether your
system is big- or little- (or middle-!) endian, try to redesign your
program so that you don't need to know this. If that's impossible, perhaps
because of some externally imposed data format, at least now you know how
to tell the difference.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
On Oct 8, 9:53 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> charp...@yahoo.com said:
>
> > Hello,

>
> > I am wondering when does the little or big endian affects the code ?

>
> Never, if you're careful and lucky.
>
> > In which cases should I check if a machine uses Little or Big Endian?

>
> If you stick to standard C and only ever have to process files that you
> have yourself produced on a single implementation, the answer is - as near
> as makes no odds - never.
>
> Normally it starts to matter when you're reading integers from a binary
> file (or writing them /to/ a binary file).
>
> > - For example does it affect bitwise operations ? eg. x >> 10

>
> No, this operates purely on the value of x, not its representation.
>
>
>
> > - Does it affect operations like accessing memory with a (char *) ?
> > (in order to access individual bytes)

>
> To access individual bytes, use an unsigned char *.
>
> "Big endian" means that the most significant values come first in the
> underlying representation. A good example is prices in a shop: when we see
> 39.99 on a pair of jeans, we know that it's about 40 currency units, not
> almost a hundred currency units. "Little endian" means that the least
> significant values come first - and I suppose the obvious example would be
> UK date format: day/month/year.
>
> So if you do something like this:
>
> int x = 1;
> unsigned char *p = (unsigned char *)&x;
> printf("%d\n", *p);
>
> it is likely to print 1 on a little-endian system, but 0 on a big-endian
> system (provided sizeof(int) is at least 2, which isn't actually
> guaranteed), whereas if you had written:
>
> int x = 1;
> unsigned char *p = (unsigned char *)&x;
> p += (sizeof x) - 1;
> printf("%d\n", *p);
>
> it is likely to print 0 on a little-endian system, but 1 on a big-endian
> system.
>
> Generally, such code is best avoided. If you need to know whether your
> system is big- or little- (or middle-!) endian, try to redesign your
> program so that you don't need to know this. If that's impossible, perhaps
> because of some externally imposed data format, at least now you know how
> to tell the difference.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999


I have 3 more questions:

- When I write data to file, is there any chance that it will show
differently in a big-endian or a little-endian macgine?

- When I am using char arrays does endianness affects how the bytes
are stored in memory or in both implementations they are stored the
same way?

- Is there any difference when using (char *) and (unsigned char *)
for accessing bytes in memory ?

Thanks for your time and fast replies

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      10-08-2007
said:

<60 lines snipped>

Please snip text that isn't relevant to your reply. This saves time for
your readers. If you don't do this, eventually people will stop bothering
to read what you write.


> I have 3 more questions:
>
> - When I write data to file, is there any chance that it will show
> differently in a big-endian or a little-endian macgine?


Yes, if you write "binary" data. This is not a problem with text files,
however. That is one of the reasons we advocate using text files where
possible.

> - When I am using char arrays does endianness affects how the bytes
> are stored in memory or in both implementations they are stored the
> same way?


An array stores elements in the order you would expect ([0] first, [1]
second, etc) - or at least it must behave as if it does, such that a
strictly conforming program can't tell the difference.

Since a char occupies exactly one byte, endianness doesn't enter into it.
Which do you want first, this apple or this apple?


> - Is there any difference when using (char *) and (unsigned char *)
> for accessing bytes in memory ?


The Standard guarantees that the object representation of an object can be
accessed via an unsigned char * - I am not aware of any such guarantee for
char *.


--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      10-08-2007
On Oct 8, 12:14 pm, charp...@yahoo.com wrote:
> On Oct 8, 9:53 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
>
>
>
>
> > charp...@yahoo.com said:

>
> > > Hello,

>
> > > I am wondering when does the little or big endian affects the code ?

>
> > Never, if you're careful and lucky.

>
> > > In which cases should I check if a machine uses Little or Big Endian?

>
> > If you stick to standard C and only ever have to process files that you
> > have yourself produced on a single implementation, the answer is - as near
> > as makes no odds - never.

>
> > Normally it starts to matter when you're reading integers from a binary
> > file (or writing them /to/ a binary file).

>
> > > - For example does it affect bitwise operations ? eg. x >> 10

>
> > No, this operates purely on the value of x, not its representation.

>
> > > - Does it affect operations like accessing memory with a (char *) ?
> > > (in order to access individual bytes)

>
> > To access individual bytes, use an unsigned char *.

>
> > "Big endian" means that the most significant values come first in the
> > underlying representation. A good example is prices in a shop: when we see
> > 39.99 on a pair of jeans, we know that it's about 40 currency units, not
> > almost a hundred currency units. "Little endian" means that the least
> > significant values come first - and I suppose the obvious example would be
> > UK date format: day/month/year.

>
> > So if you do something like this:

>
> > int x = 1;
> > unsigned char *p = (unsigned char *)&x;
> > printf("%d\n", *p);

>
> > it is likely to print 1 on a little-endian system, but 0 on a big-endian
> > system (provided sizeof(int) is at least 2, which isn't actually
> > guaranteed), whereas if you had written:

>
> > int x = 1;
> > unsigned char *p = (unsigned char *)&x;
> > p += (sizeof x) - 1;
> > printf("%d\n", *p);

>
> > it is likely to print 0 on a little-endian system, but 1 on a big-endian
> > system.

>
> > Generally, such code is best avoided. If you need to know whether your
> > system is big- or little- (or middle-!) endian, try to redesign your
> > program so that you don't need to know this. If that's impossible, perhaps
> > because of some externally imposed data format, at least now you know how
> > to tell the difference.

>
> > --
> > Richard Heathfield <http://www.cpax.org.uk>
> > Email: -http://www. +rjh@
> > Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> > "Usenet is a strange place" - dmr 29 July 1999

>
> I have 3 more questions:
>
> - When I write data to file, is there any chance that it will show
> differently in a big-endian or a little-endian macgine?
>
> - When I am using char arrays does endianness affects how the bytes
> are stored in memory or in both implementations they are stored the
> same way?
>
> - Is there any difference when using (char *) and (unsigned char *)
> for accessing bytes in memory ?
>
> Thanks for your time and fast replies- Hide quoted text -
>
> - Show quoted text -


Here's a solution to the binary files problem:
http://www.unidata.ucar.edu/software/netcdf/

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      10-08-2007
In article <. com>,
<> wrote:

> I am wondering when does the little or big endian affects the code ?


The essence of endianness is using the same address to point to things
of different sizes. Which end of the big thing does the little
thing correspond to?

So:

>- For example does it affect bitwise operations ? eg. x >> 10


No. There is no addressing of bits here, just an arithmetic operation
on a value (even if that operation is naturally expressed in terms of
bit maipulation, it doesn't involve the address of the bits).

>- Does it affect operations like accessing memory with a (char *) ?
>(in order to access individual bytes)


Yes. Here you are using the same address with two different types.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
> The Standard guarantees that the object representation of an object can be
> accessed via an unsigned char * - I am not aware of any such guarantee for
> char *


I didn't fully understood this one, can you please give me an example
when should I use char * and when unsigned char * ?

Thanks so much


 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      10-08-2007
said:

>> The Standard guarantees that the object representation of an object can
>> be accessed via an unsigned char * - I am not aware of any such
>> guarantee for char *

>
> I didn't fully understood this one, can you please give me an example
> when should I use char * and when unsigned char * ?


If you want to point at a char, use a char *.

If you want to point at an unsigned char, use an unsigned char *.

If you want to point at the first byte of an object, so that you can
examine the object representation of that object, use an unsigned char *.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      10-08-2007
wrote:

>> The Standard guarantees that the object representation of an object
>> can be accessed via an unsigned char * - I am not aware of any such
>> guarantee for char *

>
> I didn't fully understood this one, can you please give me an example
> when should I use char * and when unsigned char * ?


Use them both to point to arrays of their respective types. In addition
use unsigned char * to point to any object to examine it's actual
binary representation. The interpretation of this depends on the exact
properties of the original type in question, many which are
implementation defined.

 
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
little endian , big endian , big headache manishster@gmail.com C Programming 5 08-31-2006 12:28 AM
Little Endian to Big Endian invincible C++ 9 06-14-2005 10:21 PM
Little Endian to Big Endian for 32 bit invincible C++ 1 06-14-2005 04:20 PM
float: IEEE, big endian, little endian Ernst Murnleitner C++ 0 01-13-2004 01:48 PM
convert from BIG-ENDIAN to LITTLE-ENDIAN hicham C++ 2 07-02-2003 04:55 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57