shortening this short code? : binary to int casting

I have a 4bytes in a char buffer and I wish to cast to int.
I'm currently using the code below..

int *aa = (int*)aBuffer;
int bb = *aa;

Can i shorten this code somehow? I seem to have one more int variable than necessary.
My pointer skills are not too great.

Something like this..

int bb = (int)&aBuffer

..would be much prettier, but i can guess it does not work.

Any ideas?

You'll want to save this (honest)

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main() {
        char *Int=malloc(4);
        int X=421500666, *xx=&X;
        int OldGit; /* this one's for you */
        Int=(char*)xx;
        printf("%d\n",*(int*)Int);
        /* everything good to here...eureka! */
        OldGit=*(int*)Int;        /* !!!! */
        OldGit++;
        printf("%d\n",OldGit);
        return 0;
}

---

You're gonna love the output too.

Quote:

---

Originally Posted by MK27

You'll want to save this (honest)

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main() {
        char *Int=malloc(4);
        int X=421500666, *xx=&X;
        int OldGit; /* this one's for you */
        Int=(char*)xx;
        printf("%d\n",*(int*)Int);
        /* everything good to here...eureka! */
        OldGit=*(int*)Int;        /* !!!! */
        OldGit++;
        printf("%d\n",OldGit);
        return 0;
}

---

You're gonna love the output too.

---

Crikey! Thanks mk27 (I think) will take some time to decipher that

So...

int aa = *(int*)aBuffer;


great!

Cheers

It's slightly long winded. You don't need *xx at all, you can just say

Code:

---

Int=(char*)&X;

---

One thing you can't do is this:

Code:

---

char Int[4];

---

which is slightly strange.

Quote:

---

Originally Posted by MK27

It's slightly long winded. You don't need *xx at all, you can just say

Code:

---

Int=(char*)&X;

---

---

I dont quite follow that one, your casting with a char pointer the address of buffer, and storing in an int.

Now I'm confused. ha. But thankyou, thats solved my predicament.

Quote:

---

Originally Posted by OldGit

I dont quite follow that one, your casting with a char pointer the address of buffer, and storing in an int.

Now I'm confused. ha. But thankyou, thats solved my predicament.

---

&X would be the address of the location where the int X is stored. Remember *xx=&X? So &X points to X.

The cast allows Int (a char pointer) to point to X.

Shall I tell you about alignment exceptions and bus errors, or do you want to find that out for yourself first?

Quote:

---

Originally Posted by Salem

Shall I tell you about alignment exceptions and bus errors, or do you want to find that out for yourself first?

---

Oh please do!

Quote:

---

Originally Posted by MK27

Oh please do!

---

What Salem is referring to is that some processors (in fact most that are not x86) do not accept memory reads from unaligned addresses, e.g. a 4-byte word must be aligned to a 4-byte block in memory. Bus error is the common message from the processor for "unaligned access", but it is sometimes called other things.


Some processor & OS combinations use the exception by the processor to fetch the data byte-by-byte into a longer data item (which then takes 10-100 times longer than a single word read), other processors simply cause an error, much like invalid memory address exceptions (page-fault, segmentation violation or whatever you call it).

So for portable code, copying byte by byte is the correct thing to do.

--
Mats

Quote:

---

Originally Posted by matsp

What Salem is referring to is that some processors (in fact most that are not x86) do not accept memory reads from unaligned addresses, e.g. a 4-byte word must be aligned to a 4-byte block in memory. Bus error is the common message from the processor for "unaligned access", but it is sometimes called other things.

---

Ugg. Well, who the $%#^ doesn't use an x86 processor anyway?! I'm not sure how this applies here -- shouldn't char *Int=malloc(4) and int X be aligned properly?

Quote:

---

Some processor & OS combinations use the exception by the processor to fetch the data byte-by-byte into a longer data item (which then takes 10-100 times longer than a single word read), other processors simply cause an error, much like invalid memory address exceptions (page-fault, segmentation violation or whatever you call it).

So for portable code, copying byte by byte is the correct thing to do.

---

So you would bitshift from Int into X?

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main() {
        char *Int=malloc(4);
        int X=421500666, i;
        int OldGit=0;
        Int=(char*)&X;
        printf("%d\n",*(int*)Int);
        /* everything good to here...eureka! */

        for (i=0; i<4; i++) OldGit+=Int[i]<<i*8;
       
        printf("%d\n",OldGit);
        return 0;
}

---

For some reason this does not quite work:
421500666
421434874

??

Try:

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main() {
        unsigned char *Int=malloc(4);
        int X=421500666, i;
        int OldGit=0;
        Int=(char*)&X;
        printf("%d\n",*(int*)Int);
        /* everything good to here...eureka! */

        for (i=0; i<4; i++) OldGit+=Int[i]<<i*8;
       
        printf("%d\n",OldGit);
        return 0;
}

---

That should work ;).

The char * is signed, so some parts of the number may be negative - probably not what you want.

Yes, malloc will be aligned to (at least) the size of double, one would expect (or the size of the allocation, whichever is smaller, and again this is the MINIMUM alignment, it may well be aligned to cache-lines or some other larger boundary).

But the original post says NOTHING about malloc.



--
Mats

Quote:

---

Originally Posted by EVOEx

That should work ;).

---

It does! I am surprised, I would have thought the byte values would be the same either way, since Int is just a pointer to a (signed) int. But I guess one of the middle bytes counted as negative, because of course this works too:

Code:

---

for (i=0; i<4; i++) OldGit+=(unsigned char)Int[i]<<i*8;

---

And it works with negative numbers too.

Still don't quite get this "alignment exceptions and bus errors" scare tho.

Quote:

---

Originally Posted by MK27

Still don't quite get this "alignment exceptions and bus errors" scare tho.

---

Well, if you assume all of the world uses x86, then you can ignore it. If you ever need your code to work on Sparc, Alpha, 68K, 29K, ARM, Mips or some other processor that ISN'T x86, then any code that casts small type pointers (char *, short *, int *) to larger types (e.g. int *, long * or double * ) needs careful consideration or checking that the address is still valid for that type. If it is not (e.g. the data is in an arbitrarily aligned packet of data from a network port) then you need to shuffle bytes.

--
Mats

Quote:

---

Originally Posted by matsp

Yes, malloc will be aligned to (at least) the size of double, one would expect (or the size of the allocation, whichever is smaller, and again this is the MINIMUM alignment, it may well be aligned to cache-lines or some other larger boundary).

But the original post says NOTHING about malloc.

---

So the problem would be more if you had a longer char block, and you wanted to translate an int starting at an offset of (eg) 3? [judging by your last post I'd assume yes]

A perhaps related question: why can't this pointer be used in all this:

Code:

---

char Int[4];

---

Which Int, being the address of a 4 byte block, would be identical to

Code:

---

char Int=malloc(4);

---

but in some profound sense is not...please help....

There is one more reason not to cast to an integer which seems to be ignored here: endianess.
The string "\x01\x02\0x03\x04" would result in the number 0x04030201 in little endian processors, but in 0x01020304 in big endian computers. And yet so many people read directly from a file into a struct with integers...

True, I've never seen a big endian processor in my life. But then again, in my short live, I have only seen - at least what I know of - intel/amd 32 and 64 bits processors.

Quote:

---

Originally Posted by EVOEx

There is one more reason not to cast to an integer which seems to be ignored here: endianess.
The string "\x01\x02\0x03\x04" would result in the number 0x04030201 in little endian processors, but in 0x01020304 in big endian computers. And yet so many people read directly from a file into a struct with integers...

---

But Int was never a C string of anything. I only think this will be a problem if the endianianess of the source differs -- ie, if char *Int=*(int*)421500666 on a big end computer, and then you tried int X=*(int*)Int on another, lil' end computer. Which is the network byte order issue.

But on a single system, the bytes of X and Int will have the same byte order anyway (big or little).

Feel free to contradict me on this.

Quote:

---

Originally Posted by MK27

But Int was never a C string of anything. I only think this will be a problem if the endianianess of the source differs -- ie, if char *Int=*(int*)421500666 on a big end computer, and then you tried int X=*(int*)Int on another, lil' end computer. Which is the network byte order issue.

But on a single system, the bytes of X and Int will have the same byte order anyway (big or little).

Feel free to contradict me on this.

---

No, you're right there, I won't contradict you ;). So in this case it might be OK. And yet, I've seen it used a lot where the source was an input file or socket...

> Ugg. Well, who the $%#^ doesn't use an x86 processor anyway?
All those people who write s/w for mobile phones, DVD players, and pretty much any kind of modern consumer electronics.

You too might find yourself one day in the alligator pit, but you might just escape with flesh wounds rather than being eaten ;)

And nods to EVOEx for raising the endian issue.

Quote:

---

Originally Posted by Salem

You too might find yourself one day in the alligator pit, but you might just escape with flesh wounds rather than being eaten ;)

---

This is upsetting to me, because the main reason I want to be a computer programmer is a serious aversion to alligators.

Quote:

---

Originally Posted by MK27

So the problem would be more if you had a longer char block, and you wanted to translate an int starting at an offset of (eg) 3? [judging by your last post I'd assume yes]

A perhaps related question: why can't this pointer be used in all this:

Code:

---

char Int[4];

---

Which Int, being the address of a 4 byte block, would be identical to

Code:

---

char Int=malloc(4);

---

but in some profound sense is not...please help....

---

The compiler knows that the first thing is four chars, so it could just as well start at 0xwhatever03, because chars only need to be byte-aligned. malloc returns a void *, so it will return something aligned for doubles (or whatever the widest type is), so 0xwhatever03 could never come back.