shortening this short code? : binary to int casting

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.