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.

[Keith Thompson]

"JC" <je*******@comc ast.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_Keit h) 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*******@comc ast.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********@com cast.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_Keit h) 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********@com cast.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).