Can any body explain the output of following code

[srikanth]

static char buf[10] = {1,2,3,4,5,6,7,8};
printf("Address: %u : Val = %d \n",(int*)buf+1,*((int*)buf+1));

Thanks

Vija

[John Harrison]

"srikanth" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de...

static char buf[10] = {1,2,3,4,5,6,7,8};
printf("Address: %u : Val = %d \n",(int*)buf+1,*((int*)buf+1));

Thanks

Vija

The output of this code is completely undefined by the C++ standard. On my
computer it produced

Address: 4390348 : Val = 134678021

I don't see anything unusual there.

Perhaps if you say what it produces on your computer and why you find it
hard to understand then someone wil be able to help.

Perhaps if you convert 134678021 to hex (its 0x08070605) you will understand
better what is happening.

john

[John Carson]

"srikanth" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de

static char buf[10] = {1,2,3,4,5,6,7,8};
printf("Address: %u : Val = %d \n",(int*)buf+1,*((int*)buf+1));

Thanks

Vija

You should:

1. Say what output you are seeing, because this may be system dependent (and
is in this case).

2. Say what puzzles you about it so that we don't have to engage in guessing
games.
In the expression

(int*)buf+1

the cast operator has a higher precedence than the + operator, so buf is
first cast to a pointer-to-int and then 1 is added to this pointer to int,
using pointer arithmetic. For any type T, adding 1 to a pointer-to-T returns
the pointer value plus sizeof(T). Thus you should get the address of buf
plus sizeof(int).

In the expression

*((int*)buf+1)

you are dereferencing the last expression. Assuming sizeof(int)==4,

(int*)buf+1

will equal the address of buf[4] and the int that you get from dereferencing
it is formed from

buff[4]-buf[7],

i.e., from the values 5,6,7 and 8. What this int looks like depends on
whether your computer uses a little endian or big endian system. Intel
processors use the little endian system, which means that lower addresses
supply the less significant digits.

Thus the four digits are read as:

0x08070605

which equals

134678021 decimal.

If you have a computer that uses the big endian system, then the digits are
read as

0x05060708

which equals

84281096

decimal.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[vijay]

Thanks John,
Now I understood it well
Do you know any compiler which follows Big endian format
Regards
Vijay

[Alexander Terekhov]

vijay wrote:

Thanks John,
Now I understood it well
Do you know any compiler which follows Big endian format

http://mindprod.com/jgloss/endian.html
(What Sex Is Your CPU?)

regards,
alexander.

--
"The endian-agnostic Power-PC's have a foot in both camps. They
are bisexual, but the OS usually imposes one convention or the
other. e.g. Mac PowerPCs are big-endian. "

[vijay]

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

Vijay

[vijay]

I think I got the answer
1 Byte can have 2 power 8: 256 characters combinatins:. 2 hexadecimal
digits,(16X16)
Thanks
vijay

"vijay" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de...

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

Vijay

[Alexander Terekhov]

vijay wrote:

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

vijay, are you studying some CS Ph.D questionary, or what?

regards,
alexander.

[Josephine Schafer]

"vijay" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de...

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

Remember nibble?
A nibble is half of an eight bit byte.
So how do you represent 5 in a byte - 0x05.

[John Carson]

"vijay" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

Vijay

I am assuming that each byte is 8 bits. Taking the example of the number 5,
it is stored in 8 bits as

00000101

If you are just considering one of these numbers in isolation, then the
leading zeros don't matter. But if you are laying them end to end, then the
leading zeros become internal zeros and affect the significance of other
digits, so you can't leave them out.

Each hexadecimal digit takes 4 bits, so two are required per byte. 0x05 is
precisely

00000101

as required.

--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Thomas Matthews]

Alexander Terekhov wrote:

vijay wrote:

Thanks John,
Now I understood it well
Do you know any compiler which follows Big endian format

http://mindprod.com/jgloss/endian.html
(What Sex Is Your CPU?)

regards,
alexander.

--
"The endian-agnostic Power-PC's have a foot in both camps. They
are bisexual, but the OS usually imposes one convention or the
other. e.g. Mac PowerPCs are big-endian. "

FYI, The ARM processors can be configured either Big Endian
or Little Endian.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Alexander Terekhov]

Thomas Matthews wrote:
[...]

"The endian-agnostic Power-PC's have a foot in both camps. They
are bisexual, but the OS usually imposes one convention or the
other. e.g. Mac PowerPCs are big-endian. "

FYI, The ARM processors can be configured either Big Endian
or Little Endian.

Yeah. And since both PPC and ARM are clearly infringing upon SCO's
IP (UNIX "methods and concepts"... with respect to CPU bisexuality,
you know), they will be declared "illegal" by SCO at the next press
conference. SCO will rightfully demand that all PPC and ARM devices
shall be immediately unplugged and be prepared for destruction
(pending licensing negotiations outcome).

regards,
alexander.

--
http://www.ibm.com/servers/eserver/linux/fun

[Ron Natalie]

"Bruce" <br***@nospam.com> wrote in message news:3f*************@news.dallas.sbcglobal.net...

In comp.lang.c++
"srikanth" <ge********@yahoo.com> wrote:

static char buf[10] = {1,2,3,4,5,6,7,8};
printf("Address: %u : Val = %d \n",(int*)buf+1,*((int*)buf+1));

I assume this is for fun or learning or something? If you wrote code like
that where I work, well, you probably wouldn't work there very long.

Won't work on any platform where ints and pointers aren't coincidentally compatible.
If you want to dump pointers out with printf use %p and cast it to void* first.

[greg]

HI
ANy specific reason for the other output ???
static char buf[10] = {1,2,3,4,5,6,7,8,};
static char buf1[10]={'1','2','3','4','5','6','7','8'};
printf("Address BUF: %u : Val = %d \n",(int*)buf+1,*((int*)buf+1));
//hex conversion of output 8070605
printf("Address BUF1: %u : Val = %d
\n",(int*)buf1+1,*((int*)buf1+1)); //38373635 hex conversion of output


"Josephine Schafer" <[e-mail]> wrote in message news:<be************@ID-192448.news.dfncis.de>...

"vijay" <ge********@yahoo.com> wrote in message
news:be**********@news.mch.sbs.de...

Ya ,compilers was a typing error,
well ,why there is a padding of zero for evey hexadecimal number ie
0x08070605

Remember nibble?
A nibble is half of an eight bit byte.
So how do you represent 5 in a byte - 0x05.

[vijay]

The first case the the digits are stored directly as signed integers.
The second case they are stored as characters, ie coverting them to ascii
values and then storing them

Tyr adding the key word unsigned as characters are by default signed
static char buf[10] = {128,2,3,4,5,6,7,8};
if try to print the first char then output will be -1
if
static unsigned char buf[10] = {128,2,3,4,5,6,7,8};
then each value can take up to 255
The other array you will not be able to store even 2 digit number

Regards
vijay