From: Paolo Ornati <ornati@fastwebnet.it>
To: nanakos@wired-net.gr
Cc: linux-assembly@vger.kernel.org
Subject: Re: x86 Endiannes and libc printf
Date: Sat, 9 Jul 2005 10:19:37 +0200 [thread overview]
Message-ID: <20050709101937.0aad4448@localhost> (raw)
In-Reply-To: <42117.62.38.142.34.1120849517.squirrel@webmail.wired-net.gr>
On Fri, 8 Jul 2005 22:05:17 +0300 (EEST)
"Nanakos Chrysostomos" <nanakos@wired-net.gr> wrote:
> int main()
> {
> char *filename= "endian.txt";
> unsigned long buf;
> char *k=(char *)&buf;
> int fd;
>
> fd = open("makis",O_RDONLY);
>
> read(fd,&buf,4);
>
> printf("%.4s\n",&buf);
> printf("%p\n",buf);
> printf("&buf: %p %#x %p\n",&buf,*k,k);
> return 0;
> }
>
> endian.txt
> ----------
> DBCA
>
>
> #./read
> DCBA
> 0x41424344
> &buf: 0xbffff8b0 0x44 0xbffff8b0
> #
>
>
> In the first printf everything is fine.In the second printf we see
> that the 0x44,0x43,0x42,0x41 byte-data is printed in the revserse
> order,while we can see
> that in memory it is in the right order after the read system call.Why
> this happens?Is it being internal in printf???
No, it isn't printf... it's just that x86 CPU are little endian.
When you do:
printf("%.4s\n",&buf);
you are printing these four bytes in memory-order.
When you do:
printf("%p\n",buf);
you are treating "buf" as a single number. Since your CPU is little
endian it expects the low order bytes to come first.
Another example:
#include <stdio.h>
int main(void) {
unsigned int buf = 0x11223344;
unsigned char *x = (unsigned char*)&buf;
printf("0x%hhx\n", x[0]);
return 0;
}
printf will print 0x44... simply because the 0x11223344 numer is stored
in memory in this way:
address value
&buf 0x44
&buf+1 0x33
&buf+2 0x22
&buf+3 0x11
For more info about x86 CPU look here:
http://developer.intel.com/design/pentium4/manuals/index_new.htm
--
Paolo Ornati
Linux 2.6.12.2 on x86_64
next prev parent reply other threads:[~2005-07-09 8:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-08 19:05 x86 Endiannes and libc printf Nanakos Chrysostomos
2005-07-08 19:25 ` Vadim Lobanov
2005-07-08 20:17 ` Richard B. Johnson
2005-07-09 8:19 ` Paolo Ornati [this message]
2005-07-09 14:41 ` Nanakos Chrysostomos
2005-07-09 14:41 ` Nanakos Chrysostomos
2005-07-09 14:51 ` Robert Plantz
2005-07-09 16:31 ` Paolo Ornati
-- strict thread matches above, loose matches on Subject: below --
2005-07-06 20:15 process information Matías Aguirre
2005-07-07 12:09 ` Luiz Fernando Capitulino
2005-07-07 18:48 ` x86 Endiannes and libc printf Nanakos Chrysostomos
2005-07-09 17:43 ` Glynn Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050709101937.0aad4448@localhost \
--to=ornati@fastwebnet.it \
--cc=linux-assembly@vger.kernel.org \
--cc=nanakos@wired-net.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.