Thread: shortening this short code? : binary to int casting

  1. #16
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by matsp View Post
    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....
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #17
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    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.

  3. #18
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by EVOEx View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #19
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by MK27 View Post
    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...

  5. #20
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #21
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Salem View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #22
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Quote Originally Posted by MK27 View Post
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Debug Error Really Quick Question
    By GCNDoug in forum C Programming
    Replies: 1
    Last Post: 04-23-2007, 12:05 PM
  2. About aes
    By gumit in forum C Programming
    Replies: 13
    Last Post: 10-24-2006, 03:42 PM
  3. Game Won't Compile
    By jothesmo in forum C++ Programming
    Replies: 2
    Last Post: 04-01-2006, 04:24 PM
  4. Need help understanding info in a header file
    By hicpics in forum C Programming
    Replies: 8
    Last Post: 12-02-2005, 12:36 PM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM