Re: Unsigned Integer Encoding

2012-08-15 Thread Wojciech Puchar

/* This prints 04030201 */
printf ("b= %0X \n", *b);

all is OK, you did this probably on x86 CPU which is little endian. on 
powerpc it would be 01020304 as it is big endian.


to write endian independent code:

man htonl

all these are macros actually.

"network order" is big endian. so eg htonl would reverse order on x86, and 
ddo nothing on powerpc.



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


Re: Unsigned Integer Encoding

2012-08-15 Thread Peter Jeremy
On 2012-Aug-15 10:33:46 +0200, Daniel Grech  wrote:
>Hi,
>
>I have what is probably a really elementary question but I can't seem to
>figure it out. In the following snippet of code, why is it that a and b do
>not have the same value in the end ?  :

See http://en.wikipedia.org/wiki/Endian

>Im asking this as I am currently encoding a protocol in which i receive
>data as a sequence of bytes. Casting for example 4 bytes from this stream
>leaves me with the situation in variable b, while the situation I am
>looking to accomplish is the one in A (i.e. the bytes are not encoded in
>reverse form).

I suggest you look at xdr(3) and rpcgen(1)

-- 
Peter Jeremy


pgpSy5s1R6Dmk.pgp
Description: PGP signature


Re: Unsigned Integer Encoding

2012-08-15 Thread Václav Zeman
On 08/15/2012 10:33 AM, Daniel Grech wrote:
> Hi,
>
> I have what is probably a really elementary question but I can't seem to
> figure it out. In the following snippet of code, why is it that a and b do
> not have the same value in the end ?  :
>
> #define uint32_t unsigned int
> #define uint16_t unsigned short
> #define uint8_t unsigned char
> #define uint64_t unsigned long long
>
> int main ()
> {
> uint32_t a = 0x01020304;
>
> /* This prints 01020304 */
> printf ("a = %0X \n",a);
>
> uint32_t * b;
>
> uint8_t bytes [] = {0x01,0x02,0x03,0x04};
>
> b = (uint32_t *) bytes;
You cannot do this cast. The bytes array does not have to be
sufficiently aligned and you will get SIGBUS errors on strict alignment
platforms. Use memcpy() to copy from the bytes array to b instead, that
is the only portable way to do this.

>
> /* This prints 04030201 */
This is correct for LE platforms. The least significant byte (1) is
first in the array. You need to know which order of bytes does the
protocol use for transport (LE or BE) and then have the implementation
either swap or not swap the bytes appropriately.

> printf ("b= %0X \n", *b);
> return 1;
> }
>
> Im asking this as I am currently encoding a protocol in which i receive
> data as a sequence of bytes. Casting for example 4 bytes from this stream
> leaves me with the situation in variable b, while the situation I am
> looking to accomplish is the one in A (i.e. the bytes are not encoded in
> reverse form).
>
> Thanks in advance for your help.

-- 
VZ





signature.asc
Description: OpenPGP digital signature


Unsigned Integer Encoding

2012-08-15 Thread Daniel Grech
Hi,

I have what is probably a really elementary question but I can't seem to
figure it out. In the following snippet of code, why is it that a and b do
not have the same value in the end ?  :

#define uint32_t unsigned int
#define uint16_t unsigned short
#define uint8_t unsigned char
#define uint64_t unsigned long long

int main ()
{
uint32_t a = 0x01020304;

/* This prints 01020304 */
printf ("a = %0X \n",a);

uint32_t * b;

uint8_t bytes [] = {0x01,0x02,0x03,0x04};

b = (uint32_t *) bytes;

/* This prints 04030201 */
printf ("b= %0X \n", *b);

return 1;
}

Im asking this as I am currently encoding a protocol in which i receive
data as a sequence of bytes. Casting for example 4 bytes from this stream
leaves me with the situation in variable b, while the situation I am
looking to accomplish is the one in A (i.e. the bytes are not encoded in
reverse form).

Thanks in advance for your help.

Regards,

Daniel
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"