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

Architecture independant byte operations

P: n/a
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant. The intention is to
store two bytes, as chars, extracted from a short input parameter as:

<code>
void foo(short id_pair)
{
char *ptr = &id_pair;
memcpy(&::id1, ptr, 1);
memcpy(&::id2, prt+1, 1);
}
</code>

What is a better, architecture-independant, method of doing this?

Aug 30 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
ca******@gmail.com wrote:
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant. The intention is to
store two bytes, as chars, extracted from a short input parameter as:

<code>
void foo(short id_pair)
{
char *ptr = &id_pair;
I assume your compiler gives you a warning here.
memcpy(&::id1, ptr, 1);
memcpy(&::id2, prt+1, 1);
Why not just assign them?
}
</code>

What is a better, architecture-independant, method of doing this?
You have to correct for the byte order of the machine.

--
Ian Collins.
Aug 30 '06 #2

P: n/a
On 29 Aug 2006 19:20:43 -0700, ca******@gmail.com wrote in
comp.lang.c:
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant. The intention is to
store two bytes, as chars, extracted from a short input parameter as:

<code>
void foo(short id_pair)
{
char *ptr = &id_pair;
memcpy(&::id1, ptr, 1);
The two colons above are either a syntax error or a different
language. If the latter is the case, I suggest you ask about your
assumptions in a newsgroup for that different language.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Aug 30 '06 #3

P: n/a
ca******@gmail.com wrote:
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant.
Quite the opposite, pointer arithmetic accesses data directly by
location in RAM and by definition how an object is stored in RAM is
architecture dependent.

Maths operations on the other hand, which bitwise operations are a part
of, are defined by the C standard to be specifically architecture
independent.
<code>
void foo(short id_pair)
{
char *ptr = &id_pair;
memcpy(&::id1, ptr, 1);
memcpy(&::id2, prt+1, 1);
}
</code>

What is a better, architecture-independant, method of doing this?
Use bitwise operations:

id1 = id_pair & 0xff;
id2 = (id_pair >8) & 0xff;

Aug 30 '06 #4

P: n/a
ca******@gmail.com wrote:
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant. The intention is to
store two bytes, as chars, extracted from a short input parameter as:
Assuming abit about the sizes of a short, how about just;

unsigned char vals[2];
unsigned short i = 0x1234;

vals[0] = i&0xff;
vals[1] = i>>8&0xff;
Aug 30 '06 #5

P: n/a
carsonbj posted:
><code>
void foo(short id_pair)
{
char *ptr = &id_pair;

If your compiler compiles that without complaining about a type mismatch,
then it's not a C compiler.

memcpy(&::id1, ptr, 1);
memcpy(&::id2, prt+1, 1);
The twin colons specify the "global namespace" in C++. They're a syntax error
in C.
}
</code>
--

Frederick Gotham
Aug 30 '06 #6

P: n/a
On 30 Aug 2006 02:49:39 -0700, "sl*******@yahoo.com"
<sl*******@gmail.comwrote:
ca******@gmail.com wrote:
I have an issue where the below operation works on a little-endian
architecture but not on a big-endian architecture. I was under the
impression that pointer arithmetic is architecture independant and
bitwise operations are architecture dependant.

Quite the opposite, pointer arithmetic accesses data directly by
location in RAM and by definition how an object is stored in RAM is
architecture dependent.
Right. Or rather, type punning using pointer conversion as the OP did.
Pointer arithmetic on pointers of (or precisely to) one type within an
array _of that type_ is architecture independent (except that the
maximum _size_ of such an array is implementation dependent).
Maths operations on the other hand, which bitwise operations are a part
of, are defined by the C standard to be specifically architecture
independent.
Not entirely. Some aspects, like shifts of negative signed numbers and
overflow in signed (or non-IEEE floating) arithmetic, and sizes/ranges
of (most) types, are left to varying extents to the implementation.
<code>
void foo(short id_pair)
{
char *ptr = &id_pair;
memcpy(&::id1, ptr, 1);
memcpy(&::id2, prt+1, 1);
}
</code>

What is a better, architecture-independant, method of doing this?

Use bitwise operations:

id1 = id_pair & 0xff;
id2 = (id_pair >8) & 0xff;
To be absolutely safe, cast the second one to unsigned short, or
(probably better) make the parameter unsigned short to start with.

On an implementation with short and int both 16 bits, as is allowed
though nowadays pretty rare, if the value of id_pair is negative the
result of the shift is implementation-defined; in practice it is
either the result of a hardware unsigned/logical shift or a hardware
2sC-sign-propagating shift, and either way after masking is correct,
but the standard doesn't actually guarantee this.

- David.Thompson1 at worldnet.att.net
Sep 7 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.