Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Please explain the output

Reply
Thread Tools

Please explain the output

 
 
Jaspreet
Guest
Posts: n/a
 
      09-16-2005
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.

 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      09-16-2005
In article <(E-Mail Removed). com>,
Jaspreet <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Antonio Contreras
Guest
Posts: n/a
 
      09-16-2005
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.

 
Reply With Quote
 
Eric Laberge
Guest
Posts: n/a
 
      09-16-2005
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
 
Reply With Quote
 
Simon Biber
Guest
Posts: n/a
 
      09-16-2005
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.
 
Reply With Quote
 
Waxhead
Guest
Posts: n/a
 
      09-16-2005

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.

 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      09-16-2005
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: <(E-Mail Removed)>

 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      09-16-2005
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++


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      09-16-2005
In article <(E-Mail Removed) .com>,
Antonio Contreras <(E-Mail Removed)> 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
 
Reply With Quote
 
aegis
Guest
Posts: n/a
 
      09-17-2005

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Please explain the output bhawna C Programming 9 03-28-2011 06:46 AM
Please explain this "Why's" example please Kaye Ng Ruby 8 06-08-2010 09:13 AM
Can someone please explain the output of this code? Aarti C++ 3 07-27-2007 03:34 PM
show interfaces output - explain? JimD Cisco 1 02-28-2006 10:54 AM
Can any body explain the output of following code srikanth C++ 14 07-10-2003 05:09 AM



Advertisments