By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,837 Members | 1,732 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,837 IT Pros & Developers. It's quick & easy.

are bit manipulation guaranteed to work endian independent

P: n/a
Provided a unsigned integer say (32bits b31-b0 bits) and its required
to get (b19-b10) .

One approach is have a mask and right shift it

#define BIT_MASK 0x000FFC00

uint32 variable;

variable &= BIT_MASK
variable >>= 10

My question is, does the above code guarantee to do the same in big
and little endian machines? Or should i make sure to check the
endianess and manipulate in accord?
What is the general approach to guarantee bit manipulations on a
software works fine irrespective to endianess of h/w underneath?

Mar 15 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a

senthil...@gmail.com wrote:
Provided a unsigned integer say (32bits b31-b0 bits) and its required
to get (b19-b10) .

One approach is have a mask and right shift it

#define BIT_MASK 0x000FFC00

uint32 variable;

variable &= BIT_MASK
variable >>= 10

My question is, does the above code guarantee to do the same in big
and little endian machines? Or should i make sure to check the
endianess and manipulate in accord?
What is the general approach to guarantee bit manipulations on a
software works fine irrespective to endianess of h/w underneath?


The above will work irrespective of endinanness. Shifts and bit
manipulations are guaranteed to work as you'd expect.

The endianness only comes into play when it comes to storage (e.g.
reading/writing files).

--
BR, Vladimir

Mar 15 '06 #2

P: n/a

<se********@gmail.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...
Provided a unsigned integer say (32bits b31-b0 bits) and its required
to get (b19-b10) .

One approach is have a mask and right shift it

#define BIT_MASK 0x000FFC00

uint32 variable;

variable &= BIT_MASK
variable >>= 10

My question is, does the above code guarantee to do the same in big
and little endian machines?
Yes and no. It depends on where the value of 'variable' came from.

If the value of variable originated in your program, yes.
variable=0xFFAA55EE;
It's endianess _within_ your program transparent to you. Both little and
big endian will function correctly and identically, although the byte order
is different.

If the value of variable originated in elsewhere, say a jpeg, a zip, or
network data, no.
The values will be swapped if the transfer of data was between a big and
little endian machine.
The values will be the same if the transfer of data was from a big to a big,
or from a little to a little endian machine (with a couple of rare
exceptions).
Or should i make sure to check the
endianess and manipulate in accord?
Are the values in variable being transfered between different type machines?
(jpeg, zip, tcp/ip)
If so, you'll need to correct for endianess.
What is the general approach to guarantee bit manipulations on a
software works fine irrespective to endianess of h/w underneath?


Usually, a number of macros are or a union is defined in order to switch
around the byte order of the data.
Rod Pemberton
Mar 15 '06 #3

P: n/a
Thanks for your replies.
So files are the major concern since its a stored data in memory and
needs to be ensured about endianess.
I know network data are network byte ordered(i think little endian)
so i remember using network to host order conversion function to patch
up.

Mar 15 '06 #4

P: n/a
<se********@gmail.com> wrote in message
news:11********************@j52g2000cwj.googlegrou ps.com...
Thanks for your replies.
So files are the major concern since its a stored data in memory and
needs to be ensured about endianess.
I know network data are network byte ordered(i think little endian)
so i remember using network to host order conversion function to patch
up.


network byte order is "big-endian".
Mar 15 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.