Storing two adjacent chars in an array into an int

Question

I have this character array

char array[] = {1,2,3};     //FL, FH, Size

and I am trying to access it using pointers in such a way that I get FLFH value together, stored in an integer variable.

I did this

int val =0;
val = *(int*)array;
printf("value of p is %d\n",val);

I was expecting the result to be 12, but it was some 8-digit number which I think maybe the address of the value or something. Could anyone tell me what am I doing wrong here?

Answer 1

It's never going to give you twelve.

You're taking two one-byte values and looking at them as if they comprise a single two-byte entity. When you look at them together, you're re-interpreting their value. The integer 1 looks like this, as bits: 00000001, and 2 like this: 00000010. The compiler knows how big they are and thus will allow you to access them as individuals, but they're laid out in order in your array, right next to each other in memory.

Inspect the two bytes together as if they were an int, and you have: 0000000100000010, whose value is not 12; it's 513.

For your further reading, what you're doing is a kind of "type punning".

Answer 2

This is a bad idea, for readability and for portability. Use array[0] * 10 + array[1] if that's what you mean, and trust the the peephole optimizer to speed it up. If you must access the value via a pointer, use a char pointer and write p[0] * 10 + p[1], which is easy to understand, perfectly legal, and portable.

Reasons why your code might not work are many, and this strongly suggests that what you're trying to do is dumb, or at least that you are in over your head.

The first one is that bytes range from 0–255, not from 0–9, and so if you do use this technique, and it works, you are going to get 1*256+2 =258, not 1*10+2 = 12. You are never, ever going to get 12. The computer does not work that way. This is why you have to call a function like atoi() to convert a string like "12" to the number 12 before you can do arithmetic on it.

If you have four byte ints, that would also be why you were getting some big number out: You think you're getting 1*256+2, but you're actually getting ((1*256+2)*256+3)*256+???. Also, as chris says in the comments, in such case your array is too small anyway, whence the ??? in the previous formula.

You could try using a short instead of an int and see if that works better; a short is likely to be a 2-byte integer. But this isn't guaranteed, so it still won't be portable to systems with shorts longer than two bytes. Better practice is to find out the actual type on your system that corresponds to a two-byte integer (perhaps short, perhaps something else), and then typedef something like INT2 to be that type, and use INT2 in place of int.

Another potential problem is that your system might use a little-endian byte order, in which case the bytes in your array are in the wrong order to represent the two-byte machine integer you want, and your trick is never going to work. Even if can be made to work on your machine, it will break if you ever have to run the code on a little-endian machine. (Your comments elsewhere in this thread suggest that this is exactly what is going on.)

So just do it the easy way.

Answer 3

You didn't get the result you expected because bytes are laid out on 8 bit boundaries, so adjacent binary byte values are scaled by 256₁₀, not 10₁₀.

Also, if you cast the type of something and dereference it, the compiler will compile it but technically your program is nonconforming.^*

One problem is alignment. If you change the type with open code it may not begin at the right boundary, and it may not be big enough. You can fix all that with a union. It's still nonconforming and the result is not specified, but in practice it is reliable and even somewhat portable, if you don't mind different results depending on byte order and int size.

union a {
  char  c[3];
  int   i;
  short s;
} a;

This might also be a good application for <stdint.h>, but that's a topic for another question.

---

^{*You might wonder, then, why casts exist ... it's because (A) despite being banned by the standard, type punning is widely used in existing C programs and particularly in operating software, and (B) there are mostly-conforming uses that define generic interfaces but always (or, ahem usually) cast the thing back to the original type before dereferencing it.}

Answer 4

maybe try :-

char array[] = {1,2,3};     //FL, FH, Size
int val =0;
val = *(short*)array;
printf("value of p is %X\n",val);

this is assuming you are trying to reinterpret your char array as an int. Though different platforms you may get different results than expected.