«

I was recently asked this question in an interview. Unfortunately I was
not able to answer it and the interviewer made a decision on my C
strengths (or weekness) based on this single question and that was a
sad end to my interview. Here is the program:

#include <stdio.h>

int main()
{
char *c ="abc";
int *i=(int*)c;
printf("%x", *i);
return 0;
}

The output is:
636261.

I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
is code for b and so on. My query is why is it printing the ascii codes
in the reverse order.

I apologise if this questios is a very basic one.

In article <. com>,
Jaspreet <> wrote:
>#include <stdio.h>

>int main()
>{
> char *c ="abc";
> int *i=(int*)c;
> printf("%x", *i);
> return 0;
>}

>The output is:
>636261.

Not in general, it isn't. For example on the system I'm using,
the output is 61626300

>I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
>is code for b and so on. My query is why is it printing the ascii codes
>in the reverse order.

On systems in which the representation of integers is little-endian,
the byte order is sometimes 4321 (and sometimes 2143). The order
that an integer (or float or double) is stored into RAM is often
not the same as the internal processor in-register order.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Jaspreet wrote:
> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
> #include <stdio.h>
>
> int main()
> {
> char *c ="abc";
> int *i=(int*)c;
> printf("%x", *i);
> return 0;
> }
>
> The output is:
> 636261.
>
> I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
> is code for b and so on. My query is why is it printing the ascii codes
> in the reverse order.
>
> I apologise if this questios is a very basic one.

In first place, IIRC, this program invokes undefined behaviour because
it dereferences a pointer that has been converted to another type.
Since behaviour is undefined, the output could be anything. For all you
know there could be no output, or your computer may burn.

Besides that, you're probably in a platform with 32 bit integers that
are stored in memory in big endian format. The string "abc" is stored
in memory:

|'a'|'b'|'c'| 0 |
^
|
|
char *c

Now when you cast c to an int* and dereference it, these four bytes are
interpreted as an integer in big endian format, wich means that 0 is
the MSB and 'a' the LSB.

Jaspreet wrote:

> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
> #include <stdio.h>
>
> int main()
> {
> char *c ="abc";
> int *i=(int*)c;
> printf("%x", *i);
> return 0;
> }
>
> The output is:
> 636261.
>
> I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
> is code for b and so on. My query is why is it printing the ascii codes
> in the reverse order.
>
> I apologise if this questios is a very basic one.

Here's a hint: Big vs little endian.

--
Eric Laberge

Jaspreet wrote:
> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
> #include <stdio.h>
>
> int main()
> {
> char *c ="abc";

It's best to store pointers to string literals in a const pointer to char.

> int *i=(int*)c;

This pointer conversion has undefined behaviour; for one thing, the
pointer to char may not be aligned correctly for an int!

> printf("%x", *i);

1. the pointer may be mis-aligned
2. if sizeof(int)>4 then part of the value is uninitialised
3. the value may be a trap representation for int
4. the %x specifies an unsigned int, not a signed int
5. the stdout stream should end with a newline character

> return 0;
> }
>
> The output is:
> 636261.

That's just one possible result of the undefined behaviour.

--
Simon.

Jaspreet wrote:
> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
> #include <stdio.h>
>
> int main()
> {
> char *c ="abc";
> int *i=(int*)c;
> printf("%x", *i);
> return 0;
> }
>
> The output is:
> 636261.

The system who produces this output is a little endian system (x86), if
you run the same code on a big endian system (for example a MC68000
compatible) you will get the output you might expect.

Jaspreet wrote:
>
> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
[... program to output *(int *)"abc" in hex ...]
>
> The output is:
> 636261.
>
> I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
> is code for b and so on. My query is why is it printing the ascii codes
> in the reverse order.
>
> I apologise if this questios is a very basic one.

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

(We're ignoring all of the non-portability issues in the program, of
course.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

Jaspreet wrote on 16/09/05 :
> I was recently asked this question in an interview. Unfortunately I was
> not able to answer it and the interviewer made a decision on my C
> strengths (or weekness) based on this single question and that was a
> sad end to my interview. Here is the program:
>
> #include <stdio.h>
>
> int main()
> {
> char *c ="abc";
> int *i=(int*)c;

Undefined behaviour (UB). There is no guarantee that the address of a
string literal is correctly aligned for a int.

> printf("%x", *i);

Undefined behaviour. "%x" expects an unsigned int.

A '\n' is missing (unterminated line). The result may appear or not.

> return 0;
> }
>
> The output is:
> 636261.

Once the UB's fixed, the behaviour is implementation-dependent (size of
an int, endianness, charset). The result is target-dependent. It can't
be explainded without knowing the details of the implementation.

> I know that hex 61 is decimal 97 which is the ASCII code for a. hex 62
> is code for b and so on. My query is why is it printing the ascii codes
> in the reverse order.

Try on a Mac...

> I apologise if this questios is a very basic one.

This question is idiotic. The interviewer is a idiot. The company that
hires such an idiotic is simply going to die. Try another place.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

In article < .com>,
Antonio Contreras <> wrote:
>In first place, IIRC, this program invokes undefined behaviour because
>it dereferences a pointer that has been converted to another type.
>Since behaviour is undefined, the output could be anything.

-As written- your statement ignores (char *) access, which -is-
legal (but makes no promises about what you get when you read
out internal padding bytes.)


>Besides that, you're probably in a platform with 32 bit integers that
>are stored in memory in big endian format. The string "abc" is stored
>in memory:

>|'a'|'b'|'c'| 0 |
> ^
> |
> |
>char *c

>Now when you cast c to an int* and dereference it, these four bytes are
>interpreted as an integer in big endian format, wich means that 0 is
>the MSB and 'a' the LSB.

Just the opposite: "big endian" means that the address is of the
"big end", which is to say the MSB.

The claimed output will occur only for a subset of "little endian" systems.
--
"I will speculate that [...] applications [...] could actually see a
performance boost for most users by going dual-core [...] because it
is running the adware and spyware that [...] are otherwise slowing
down the single CPU that user has today" -- Herb Sutter

Simon Biber wrote:
> Jaspreet wrote:
> > I was recently asked this question in an interview. Unfortunately I was
> > not able to answer it and the interviewer made a decision on my C
> > strengths (or weekness) based on this single question and that was a
> > sad end to my interview. Here is the program:
> >
> > #include <stdio.h>
> >
> > int main()
> > {
> > char *c ="abc";
>
> It's best to store pointers to string literals in a const pointer to char.
>
> > int *i=(int*)c;
>
> This pointer conversion has undefined behaviour; for one thing, the
> pointer to char may not be aligned correctly for an int!

In what regard is it undefined behavior? The conversion will produce an
implementation defined value. Subsequent use by dereferencing it may
invoke undefined behavior though.

--
aegis