470,821 Members | 2,032 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,821 developers. It's quick & easy.

syntax meaning

Hi i am new to this C programming.
Can anyone please let me know how can i understand this syntax:
char *c=(char*)a;

the program is:
int a[2]={ 0x01020304,0x05060708};
char b[8]={1,2,3,4,5,6,7,8};
char *c=(char*)a; <-----------------------------what does this command do??
int i;
printf("\n");
for(i=0;i<8;i++)
printf("%d",c[i]);
Jun 28 '08 #1
5 2102
Meetee
931 Expert Mod 512MB
Hi i am new to this C programming.
Can anyone please let me know how can i understand this syntax:
char *c=(char*)a;

the program is:
int a[2]={ 0x01020304,0x05060708};
char b[8]={1,2,3,4,5,6,7,8};
char *c=(char*)a; <-----------------------------what does this command do??
int i;
printf("\n");
for(i=0;i<8;i++)
printf("%d",c[i]);
Hi,
This is called typecasting in C. here you have taken a as an array of integer, and C as a char *. Now you want to assign c as a value of a. So you need to type-cast int a to char*. And that is why...!

Hope you got it :)
Regards
Jun 28 '08 #2
Hi,
This is called typecasting in C. here you have taken a as an array of integer, and C as a char *. Now you want to assign c as a value of a. So you need to type-cast int a to char*. And that is why...!

Hope you got it :)
Regards

Hi
thanks for the reply Zodilla
I'm a bit confused .

firstly i think in the command
char *c=(char*)a
the c should contain the address(while *c points toward the contents) of type casted a array,and in the last line of the program when we printf c[i] ,isnt it meant to print the addresses .How does it print the 8bit values?


Secondly the program outputs :4 3 2 1 8 7 6 5,picking 8bit lower values 1st.How can i visualize that looking at the array.

Best regards
Jun 28 '08 #3
char *c=(char*)a;

*c is a pointer variable.(All pointers have * at the begining)
A pointer is variable that stores the address of a location in memory.

(char*)a here a is a int array but you are putting it in a char pointer.
Hence (char*) is a forced type conversion (c style cast).

So the over all action is that the address of the first element of array a is placed in *c.
You can understand this code better if u make a small change to the code and eecute it.
char *c=(char*)b;
Now the following loop will print contents of array b.
Jun 28 '08 #4
When you define:

Expand|Select|Wrap|Line Numbers
  1. int a[2]={ 0x01020304,0x05060708};
Assuming you're working on a 32-bit platform (say, a PC which is not 64bit), we can say following:

a[0] is a 32-bit signed integer value, e.g. occupies 32-bit in memory (4 byte addresses), and has value 0x01020304. Its address can either be referenced by saying &a[0], or simply a (yes, the beginning address of an array can be always retrieved by simply typing its name). So, we can say &a[0] == a.

On the other hand, a[1] has contents 0x05060708. Its address is &a[1], which, by definition, will be 4 byte memory positions after &a[0] (since each element occupies 4 bytes in memory).

So, if you do a[0], you get the contents in address 'a'. If you do a[1] you get the contents of address 'a + 4 byte memory positions'. In general, we could say for 'a' that a[n] is 'a + ('n' 4 byte memory position jumps)'.

Now you do:

Expand|Select|Wrap|Line Numbers
  1. char *c=( char * )a;
What you're doing is declaring a pointer to a char (char occupies a byte), and making it point to "a", which is the starting address of your array 'a'. The casting (char *) is to avoid a warning from the compiler (if it was not there, the compiler would complain, so you're assigning a pointer to char to an address that the compiler knows that DOES NOT contain a char, but an int. Anyway, you tell the compiler you know what you're doing, by adding the cast. It does not issue a warning then.

Then, following the same logic, when you do c[0], c[1], c[2] you're not "jumping" in steps of 4 bytes in terms of memory addresses, as you did before with a[0] and a[1]. Since it is a pointer to char, you're jumping byte to byte. So, c[0] is the byte in address 'a', c[1] is the byte in address 'a plus one memory position', and so on.

Assuming that your platform is little endian (e.g., it is storing the numbers upside-down in memory), then you get your result.

Relationship between pointers and arrays may be difficult to catch at first sight, but it is really not that hard. I'm sure you'll find dozens of webpages explaining how they work.
Jun 28 '08 #5
oler1s
671 Expert 512MB
firstly i think in the command char *c=(char*)a
the c should contain the address(while *c points toward the contents
c is a pointer, but *c is the pointed type itself. So *c would be a char. Itís not a pointer.

in the last line of the program when we printf c[i] ,isnt it meant to print the addresses
No itís not. Reread your book on pointers and arrays (if you have a good book). Or google for the C FAQ, which should give you a better idea of how they relate to one another. If you subscript the pointer, itís like subscripting the array. You get the value stored in the array.

Secondly the program outputs :4 3 2 1 8 7 6 5,picking 8bit lower values 1st.How can i visualize that looking at the array.
The code makes some assumptions about the machine it is being run on. That int is 4 bytes and char is 1 byte, and that a byte will be translated to 8 bits when compiled. And your output reveals your machine to be little-endian.

In a, the two integers are (guaranteed) contiguous from the view of C++. If you have a 4 byte int, you can think of it as composed of 4 1 byte chars. Or in total two ints or 8 chars.

So you have from a byte perspective: 01 02 03 04 05 06 07 08. Just one hitch though. Thatís not necessarily how itís layed out in memory. When you point to the ints with a char, you have no guarantee of how the ints were stored. On a little endian machine, they get stored as 04030201 08070605. The char doesnít interpret each block of 4 bytes as an int. It just operates on one byte at a time, so you get the 4, 3, 2, and 1. Then the 8, 7, 6, and 5.
Jun 28 '08 #6

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

699 posts views Thread by mike420 | last post: by
22 posts views Thread by Tuang | last post: by
75 posts views Thread by David MacQuigg | last post: by
14 posts views Thread by Sandy Norton | last post: by
7 posts views Thread by Steven Bethard | last post: by
41 posts views Thread by John Marshall | last post: by
8 posts views Thread by Jan van Veldhuizen | last post: by
8 posts views Thread by Rich Grise | last post: by
8 posts views Thread by aleksandar.ristovski | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.