This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: B19.1: memcpy bug (NT)
- To: "Vincent S. Perun" <Vincent dot S dot Perun at jpl dot nasa dot gov>
- Subject: Re: B19.1: memcpy bug (NT)
- From: "$Bill Luebkert" <dbe at wgn dot net>
- Date: Sat, 22 Aug 1998 18:21:56 -0700
- CC: "gnu-win32 at cygnus dot com" <gnu-win32 at cygnus dot com>
- Organization: DBE Collectibles
- References: <Pine.SOL.3.91.980821074602.26659A-100000@object.jpl.nasa.gov>
Vincent S. Perun wrote:
>
> Hello. I've discovered a bug with memcpy under beta 19.1 and NT 4.0. It
> seems the contents of a char array don't copy into an int in the right order:
> The bytes are reversed! This test expects the output to be "ABCD" but it
> puts out "CDAB". A char to char memcpy works just fine!
>
> Vincent Perun
>
> Test program:
>
> main()
> {
> unsigned char s1[2] = {0xAB, 0xCD};
> unsigned short n;
> unsigned char s2[2];
>
> memcpy (&n, &s1, 2);
> printf ("n: %4.4X\n", n);
> memcpy (&s2, &s1, 2);
> printf ("s2: %2.2X%2.2X\n", s2[0], s2[1]);
> }
You are running this on an Intel platform, right? This is expected
behavior if so.
Intel uses little-endian byte storage which means that the value
stored in a short are byte reversed from what you would have on a
big-endian machine. IE: bytes are stored from the right of a register
to the first location in memory and successive bytes to the left in
the register are stored in higher numbered memory locations.
Add this after the first printf to print it out forward:
(void)printf ("n: %2.2X%2.2X\n", n & 0xff, (n & 0xff00) >> 8);
You may need to do a little study on machine architecture. :)
PS: I worked at JPL for 21 years. How's things going over there?
--
,-/- __ _ _ $Bill Luebkert ICQ=14439852
(_/ / ) // // DBE Collectibles
/ ) /--< o // // Mailto:dbe@wgn.net
-/-' /___/_<_</_</_ http://www.wgn.net/~dbe/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".