Architecture independant byte operations

[carsonbj]

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?

 

[Ian Collins]

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.

 

[Jack Klein]

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.

 

[slebetman]

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;

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

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;

 

[Frederick Gotham]

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.

 

[Dave Thompson]

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.

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