Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #102814 > unrolled thread

Differnce order when you copy one to another

Back to article view | Back to comp.lang.c

Contents

  Differnce order when you copy one to another thunderbirdmember@gmail.com - 2017-01-30 18:08 -0800
    Re: Differnce order when you copy one to another Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-30 21:16 -0500
    Re: Differnce order when you copy one to another Koivu <market@otherb.com> - 2017-01-31 02:24 +0000
    Re: Differnce order when you copy one to another Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-01-30 19:33 -0700
    Re: Differnce order when you copy one to another "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 21:35 -0500
    Re: Differnce order when you copy one to another Keith Thompson <kst-u@mib.org> - 2017-01-31 09:00 -0800

#102814 — Differnce order when you copy one to another

 Check this out. 
This is two identical 
operations that produce two oppositely different 
strings, that were supposed to be identical. 

<u>
#include<stdio.h> //printf
#include<stdlib.h> //for exit(0); u_int32_t; malloc
#include<string.h> //bcopy


int main() {

	u_int32_t host;
	u_int8_t guest[4];
	
	guest[0] = 1;
	guest[1] = 2;
	guest[2] = 3;
	guest[3] = 4;
	
	host = guest[0] << 24 | guest[1] << 16 | guest[2] << 8 | guest[3]; 
	

	
	
	printf("%x\n", host);  //  Prints "1020304"
	
	u_int32_t host2;
	

	bcopy( guest, &host2, 4);
	
	
	printf("%x\n", host2); //  Prints  "4030201", which is opposite order.

	
}

</u>


 This cannot be  interpreted, as the string appears to be in the other 
direction as to what it was supposed to be in. 
 If English was to be from right to left then it would be a normal order. 
But when it is not it isn't.
 

[toc] | [next] | [standalone]

#102815

On 1/30/2017 9:08 PM, thunderbirdmember@gmail.com wrote:
>  Check this out. 
> This is two identical 
> operations that produce two oppositely different 
> strings, that were supposed to be identical. 
> 
> <u>
> #include<stdio.h> //printf
> #include<stdlib.h> //for exit(0); u_int32_t; malloc
> #include<string.h> //bcopy
> 
> 
> int main() {
> 
> 	u_int32_t host;
> 	u_int8_t guest[4];
> 	
> 	guest[0] = 1;
> 	guest[1] = 2;
> 	guest[2] = 3;
> 	guest[3] = 4;
> 	
> 	host = guest[0] << 24 | guest[1] << 16 | guest[2] << 8 | guest[3]; 
> 	
> 
> 	
> 	
> 	printf("%x\n", host);  //  Prints "1020304"
> 	
> 	u_int32_t host2;
> 	
> 
> 	bcopy( guest, &host2, 4);
> 	
> 	
> 	printf("%x\n", host2); //  Prints  "4030201", which is opposite order.
> 
> 	
> }
> 
> </u>
> 
> 
>  This cannot be  interpreted, as the string appears to be in the other 
> direction as to what it was supposed to be in. 
>  If English was to be from right to left then it would be a normal order. 
> But when it is not it isn't.
>  
> 

Google for  "big endian" and "little endian".


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#102816

Time for a RISC machine ../

[toc] | [prev] | [next] | [standalone]

#102818

thunderbirdmember@gmail.com writes:

>  Check this out. 
> This is two identical 
> operations that produce two oppositely different 
> strings, that were supposed to be identical. 
>
> <u>
> #include<stdio.h> //printf
> #include<stdlib.h> //for exit(0); u_int32_t; malloc
> #include<string.h> //bcopy
>
>
> int main() {
>
> 	u_int32_t host;
> 	u_int8_t guest[4];
> 	
> 	guest[0] = 1;
> 	guest[1] = 2;
> 	guest[2] = 3;
> 	guest[3] = 4;
> 	
> 	host = guest[0] << 24 | guest[1] << 16 | guest[2] << 8 | guest[3]; 
> 	
>
> 	
> 	
> 	printf("%x\n", host);  //  Prints "1020304"
> 	
> 	u_int32_t host2;
> 	
>
> 	bcopy( guest, &host2, 4);
> 	
> 	
> 	printf("%x\n", host2); //  Prints  "4030201", which is opposite order.
>
> 	
> }
>
> </u>
>
>
>  This cannot be  interpreted, as the string appears to be in the other 
> direction as to what it was supposed to be in. 
>  If English was to be from right to left then it would be a normal order. 
> But when it is not it isn't.
>  

It isn't English, it's C on a little-endian machine.
https://en.wikipedia.org/wiki/Endianness

[toc] | [prev] | [next] | [standalone]

#102819

On 01/30/2017 09:08 PM, thunderbirdmember@gmail.com wrote:
>  Check this out.
> This is two identical
> operations that produce two oppositely different
> strings, that were supposed to be identical.
>
> <u>
> #include<stdio.h> //printf
> #include<stdlib.h> //for exit(0); u_int32_t; malloc
> #include<string.h> //bcopy
>
> int main() {
> 	u_int32_t host;
> 	u_int8_t guest[4];
> 	guest[0] = 1;
> 	guest[1] = 2;
> 	guest[2] = 3;
> 	guest[3] = 4;
> 	host = guest[0] << 24 | guest[1] << 16 | guest[2] << 8 | guest[3];
> 	
>
> 	printf("%x\n", host);  //  Prints "1020304"
> 	u_int32_t host2;
> 	
> 	bcopy( guest, &host2, 4);
> 	
> 	printf("%x\n", host2); //  Prints  "4030201", which is opposite order.
> }
>
> </u>
>  This cannot be  interpreted, as the string appears to be in the other
> direction as to what it was supposed to be in.
>  If English was to be from right to left then it would be a normal order.
> But when it is not it isn't.

It would be more accurate to say that you had incorrect expectations as 
to what order it was supposed to be in.
See <https://en.wikipedia.org/wiki/Endianness>
The C standard allows data to be stored in big-endian, little-endian, 
and middle-endian formats, though the first two are, by far, the most 
common. Different types on the same machine might even have different 
byte orders - which could be useful if you have a frequent need to 
convert between those formats.

It's actually much worse than that - C leaves the order of the bits 
within an object completely unspecified. In principle, the bits 
representing values of 1, 2, 4, 8, 16, 32, 64, and 128 need not all 
reside in the same byte - they could, for instance, each reside in a 
different byte of of an 8-byte integer type. You're not likely to ever 
see anything like that - but it's not because the C standard prohibits 
it, it's only because no one has ever come up with a good reason to do 
anything like that.

[toc] | [prev] | [next] | [standalone]

#102850

thunderbirdmember@gmail.com writes:
[...]
> #include<stdio.h> //printf
> #include<stdlib.h> //for exit(0); u_int32_t; malloc

u_int32_t is non-standard.  Use the standard uint32_t, defined in
<stdint.h>.

> #include<string.h> //bcopy

bcopy() is also non-standard.  Use memcpy() instead.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web