byte to LONG

[Magix]

I received byte by byte
0x8E byte1
0x3D byte2

0x64 byte3
0x5F byte4

How can I construct to be LONG 0x645F8E3D (shift left >> 16)

Thanks.

[Thomas Stegen]

Magix wrote:

I received byte by byte
0x8E byte1
0x3D byte2

0x64 byte3
0x5F byte4

How can I construct to be LONG 0x645F8E3D (shift left >> 16)

Determine where each by should go and then shift it there and then
bitwise or it with a long.

long result = 0;
unsigned char byte2 = 0x3D;

result |= byte2 << 8;

You can figure out the rest from there I guess.

(I have made the assumption that an unsigned char is 8 bits in the above
and that long is at least twice as large an unsigned char. Not
unreasonable, but not guaranteed. To get around the bytes are not 8 bits
problem you can use CHAR_BIT instead of 8, result |= byte2 << CHAR_BIT;)

--
Thomas.

[pete]

Thomas Stegen wrote:

Magix wrote:

I received byte by byte
0x8E byte1
0x3D byte2

0x64 byte3
0x5F byte4

How can I construct to be LONG 0x645F8E3D (shift left >> 16)

Determine where each by should go and then shift it there and then
bitwise or it with a long.

long result = 0;
unsigned char byte2 = 0x3D;

result |= byte2 << 8;

You can figure out the rest from there I guess.

(I have made the assumption that an unsigned char is 8 bits
in the above
and that long is at least twice as large an unsigned char.

I don't think that you made that assumption.
A portable expression to make a long unsigned value of
0x645F8E3D, out of those byte values, is:

(((long unsigned)byte3 << 24)
+ ((long unsigned)byte4 << 16)
+ (( unsigned)byte1 << 8)
+ byte2)

CHAR_BIT isn't part of it.

--
pete

[Nils O. Selåsdal]

On Sat, 09 Oct 2004 02:22:25 +0000, pete wrote:

A portable expression to make a long unsigned value of

What about where sizeof(long) < 4 ? Or endianess ?

[Chris Torek]

>On Sat, 09 Oct 2004 02:22:25 +0000, pete wrote:

A portable expression to make a long unsigned value of ...

In article <news:pa****************************@Utel.no>
Nils O. Selåsdal <NO*@Utel.no> wrote:What about where sizeof(long) < 4 ?
Not a problem, because even if sizeof(long)==1, unsigned long
must still be at least 32 bits long, and hence hold values up
to 0xffffffffUL inclusive.
Or endianess ?

Not a problem either -- the expression depends only on the values
of the inputs, not their representations.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

pete <pf*****@mindspring.com> writes:
[...]

A portable expression to make a long unsigned value of
0x645F8E3D, out of those byte values, is:

(((long unsigned)byte3 << 24)
+ ((long unsigned)byte4 << 16)
+ (( unsigned)byte1 << 8)
+ byte2)

CHAR_BIT isn't part of it.

Assuming that the input bytes are 8-bit bytes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

pete <pf*****@mindspring.com> writes:
[...]

A portable expression to make a long unsigned value of
0x645F8E3D, out of those byte values, is:

(((long unsigned)byte3 << 24)
+ ((long unsigned)byte4 << 16)
+ (( unsigned)byte1 << 8)
+ byte2)

CHAR_BIT isn't part of it.

Assuming that the input bytes are 8-bit bytes.

Absolutely not.
There is no value of CHAR_BIT which could cause the value
of above said expression, to equal anything other than 0x645F8E3DLU
when the values below are used in the expression.
0x8E byte1
0x3D byte2
0x64 byte3
0x5F byte4

--
pete

[CBFalconer]

Keith Thompson wrote:

pete <pf*****@mindspring.com> writes:

[...]

A portable expression to make a long unsigned value of
0x645F8E3D, out of those byte values, is:

(((long unsigned)byte3 << 24)
+ ((long unsigned)byte4 << 16)
+ (( unsigned)byte1 << 8)
+ byte2)

CHAR_BIT isn't part of it.

Assuming that the input bytes are 8-bit bytes.

No, assuming they have values in the range 0..255.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

Keith Thompson wrote:

pete <pf*****@mindspring.com> writes:
[...]

> A portable expression to make a long unsigned value of
> 0x645F8E3D, out of those byte values, is:
>
> (((long unsigned)byte3 << 24)
> + ((long unsigned)byte4 << 16)
> + (( unsigned)byte1 << 8)
> + byte2)
>
> CHAR_BIT isn't part of it.

Assuming that the input bytes are 8-bit bytes.

Absolutely not.
There is no value of CHAR_BIT which could cause the value
of above said expression, to equal anything other than 0x645F8E3DLU
when the values below are used in the expression.
0x8E byte1
0x3D byte2
0x64 byte3
0x5F byte4

You're right, my mistake. I paid insufficient attention to the
original question, which asked specifically about constructing the
value 0x645F8E3D from the input bytes 0x8E, 0x3D, 0x64, and 0x5F.

If I wanted to do this kind of thing on a system with CHAR_BIT != 8
I'd probably want to re-examine the underlying assumptions, but the
problem as stated didn't actually make any assumptions about CHAR_BIT
(though it did implicitly assume that the bytes are either unsigned or
wider than 8 bits).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[JC]

Since you got the four received bytes:

unsigned long l;
char *p;

p = (char *)&l;
*p = byte_2; /* 0x3d, Assuming little endian */
*(p+1) = byte_1; /* 0x8e */
*(p+2) = byte_4; /* ox5f */
*(p+3) = byte_3; /* ox64 */

Now you should contains 0x645f8e3d; well, you get the idea...

"CBFalconer" <cb********@yahoo.com> wrote in message
news:41**************@yahoo.com...

Keith Thompson wrote:

pete <pf*****@mindspring.com> writes:

[...]

A portable expression to make a long unsigned value of
0x645F8E3D, out of those byte values, is:

(((long unsigned)byte3 << 24)
+ ((long unsigned)byte4 << 16)
+ (( unsigned)byte1 << 8)
+ byte2)

CHAR_BIT isn't part of it.

Assuming that the input bytes are 8-bit bytes.

No, assuming they have values in the range 0..255.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

"JC" <je*******@comcast.net> writes:

Since you got the four received bytes:

unsigned long l;
char *p;

p = (char *)&l;
*p = byte_2; /* 0x3d, Assuming little endian */
*(p+1) = byte_1; /* 0x8e */
*(p+2) = byte_4; /* ox5f */
*(p+3) = byte_3; /* ox64 */

Now you should contains 0x645f8e3d; well, you get the idea...

JC, please don't top-post. Your response should follow the quoted
material to which you're responding. See most of the articles in this
newsgroup for examples.

Your solution makes several unnecessary assumptions about the
representation of unsigned long; you assume that it's little endian,
and that it's exactly 4 bytes wide (if it's wider, you're leaving part
of l uninitialized). Your solution could also break if unsigned long
has padding bits or if plain char is signed. pete already posted (and
you quoted) a solution that doesn't make any of these assumptions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

"JC" <je*******@comcast.net> writes:

Since you got the four received bytes:

unsigned long l;
char *p;

p = (char *)&l;
*p = byte_2; /* 0x3d, Assuming little endian */
*(p+1) = byte_1; /* 0x8e */
*(p+2) = byte_4; /* ox5f */
*(p+3) = byte_3; /* ox64 */

Now you should contains 0x645f8e3d; well, you get the idea...

JC, please don't top-post. Your response should follow the quoted
material to which you're responding. See most of the articles in this
newsgroup for examples.

Your solution makes several unnecessary assumptions about the
representation of unsigned long; you assume that it's little endian,
and that it's exactly 4 bytes wide (if it's wider, you're leaving part
of l uninitialized). Your solution could also break if unsigned long
has padding bits or if plain char is signed. pete already posted (and
you quoted) a solution that doesn't make any of these assumptions.

His solution also assumes 8 bit bytes. If CHAR_BIT were 16,
then there would be pairs of 0's sprinkled throughout
the hexadecimal representation of that result.

--
pete

[Merrill & Michele]

JC wrote
p = (char *)&l;
*p = byte_2; /* 0x3d, Assuming little endian */
*(p+1) = byte_1; /* 0x8e */
*(p+2) = byte_4; /* ox5f */
*(p+3) = byte_3; /* ox64 */

Now you should contains 0x645f8e3d; well, you get the idea...

Keith wrote:
Your solution makes several unnecessary assumptions about the
representation of unsigned long; you assume that it's little endian,
and that it's exactly 4 bytes wide (if it's wider, you're leaving part
of l uninitialized). Your solution could also break if unsigned long
has padding bits or if plain char is signed. pete already posted (and
you quoted) a solution that doesn't make any of these assumptions.

Pete wrote:
His solution also assumes 8 bit bytes. If CHAR_BIT were 16,
then there would be pairs of 0's sprinkled throughout
the hexadecimal representation of that result.

I've been following this thread, and I still don't get it. Exactly how is
it that Pete's soln isn't married to 8 bit bytes when his left shifts were
hard coded as multiples of eight? MPJ

[Keith Thompson]

"Merrill & Michele" <be********@comcast.net> writes:

> > JC wrote
> > p = (char *)&l;
> > *p = byte_2; /* 0x3d, Assuming little endian */
> > *(p+1) = byte_1; /* 0x8e */
> > *(p+2) = byte_4; /* ox5f */
> > *(p+3) = byte_3; /* ox64 */
> >
> > Now you should contains 0x645f8e3d; well, you get the idea... >Keith wrote:
> Your solution makes several unnecessary assumptions about the
> representation of unsigned long; you assume that it's little endian,
> and that it's exactly 4 bytes wide (if it's wider, you're leaving part
> of l uninitialized). Your solution could also break if unsigned long
> has padding bits or if plain char is signed. pete already posted (and
> you quoted) a solution that doesn't make any of these assumptions.

Pete wrote:
His solution also assumes 8 bit bytes. If CHAR_BIT were 16,
then there would be pairs of 0's sprinkled throughout
the hexadecimal representation of that result.

I've been following this thread, and I still don't get it. Exactly how is
it that Pete's soln isn't married to 8 bit bytes when his left shifts were
hard coded as multiples of eight? MPJ

The original question was:

] I received byte by byte
] 0x8E byte1
] 0x3D byte2
]
] 0x64 byte3
] 0x5F byte4
]
] How can I construct to be LONG 0x645F8E3D (shift left >> 16)

The input values are treated as octets (which may or may not be
bytes).

Ignoring the "(shift left >> 16)" (I'm not sure what it means), the
requirement is to shove the specified values into 8-bit chunks of an
unsigned long. Pete's solution accomplishes that even if CHAR_BIT!=8.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Old Wolf]

"Merrill & Michele" <be********@comcast.net> wrote:

I've been following this thread, and I still don't get it. Exactly how is
it that Pete's soln isn't married to 8 bit bytes when his left shifts were
hard coded as multiples of eight? MPJ

The original question has nothing to do with bytes.
Consider this analogous question:

"How do I get (in decimal) 12345678 from the values
12, 34, 56, 78" ?

The answer is: 12 * 10^6 + 34 * 10^4 + 56 * 10^2 + 78
(where ^ means "power of").

Nothing to do with byte units. Similarly in hexadecimal:

0x645F8E3D == 0x64 * 16^6 + 0x5F * 16^4 + 0x8E * 16^2 + 0x3D

This is exactly analogous to the decimal example -- no mention
of byte units here either.
Note that each hex nibble is 4 bits, so multiplying by 16
is the same as left-shifting by 4 bits (regardless of the
byte size).