All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.