Thread: Data type consistency

  1. #1
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489

    Question Data type consistency

    Why when we allocating memory block using (ma|re|c)alloc we use sizeof([count *] primitive data type)?

    E.g.
    Code:
    int *a = malloc(5 * sizeof(int)); //allocating 5 blocks of int
    Instead of
    Code:
    #define INT_SIZE 4
    int *a = malloc(5 * INT_SIZE);
    But, I'm not talking about
    Code:
    #define int char
    Is there possibility that sizeof(int) could be changed to (for example) 2 or 16?

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Yes, the size of int may be different on different platforms.

    Incidentally I believe this is even more better:
    Code:
    int* p = malloc(5 * sizeof(*p));
    This way, should you change the variable type you won't end up with:
    Code:
    short* p = malloc(5 * sizeof(int));
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Registered User
    Join Date
    Oct 2007
    Posts
    242
    The size of int depends on the processor (changes between different architectures - 16bit processors = 2 bytes, 32bit = 4 bytes, 64bit = 8 bytes, and this will be the size of the memory registers and others)
    Although some people told me it depends on the compiler (they showed me a proof - compiled sizeof(int) in Borland CPP and on Dev CPP and the results were different - 2 for Borland and 4 for Dev CPP)

  4. #4
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    Quote Originally Posted by eXeCuTeR View Post
    Although some people told me it depends on the compiler (they showed me a proof - compiled sizeof(int) in Borland CPP and on Dev CPP and the results were different - 2 for Borland and 4 for Dev CPP)
    I would imagine that the Borland compiler was of the fossil variety (compiled only 16-bit executables). Which is why sizeof(int) was 2.

  5. #5
    Registered User
    Join Date
    Oct 2007
    Posts
    242
    Quote Originally Posted by swoopy View Post
    I would imagine that the Borland compiler was of the fossil variety (compiled only 16-bit executables). Which is why sizeof(int) was 2.
    Do you have any proof that it depends on the processor? I gotta figure what's right.

  6. #6
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    It depends more on the compiler than the processor. Sure, different processors have different optimal data sizes, but it's the compiler that makes the decisions. For example, 32-bit processors can use 64-bit data types, too, just a bit slower.

    On all current x86-64 compilers I know and/or have used, both on 64-bit Windows and 64-bit Linux, sizeof(int) is still 4, for backward compatibility.

  7. #7
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    It should depend on both, but int is intended to be the "native" integer size -- that is the size that the processor is built to handle most efficiently. For your typical Intel x86 processor that's 4 bytes. But it is up to the compiler to determine what that native size is, and principally it could be configured differently than expected.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  8. #8
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by anon View Post
    Yes, the size of int may be different on different platforms.

    Incidentally I believe this is even more better:
    Code:
    int* p = malloc(5 * sizeof(*p));
    Unless p == NULL, in which case *p will blow up.

  9. #9
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    why so?

    Code:
    #include <stdio.h>
    
    int main() {
            int *p = NULL;
            printf("&#37;d", sizeof(*p)); // 4
    }
    works for me. (32-bit Linux, gcc 4.1.2)

  10. #10
    Registered User
    Join Date
    Oct 2007
    Posts
    242
    Quote Originally Posted by cpjust View Post
    Unless p == NULL, in which case *p will blow up.
    What happens if p points to null? *p will still remain as an int, wouldn't it?

  11. #11
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    The sizeof operator is special in this case, I believe, since it's macro. No actual dereferencing is really taking place afaik.

  12. #12
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    Quote Originally Posted by cpjust View Post
    Unless p == NULL, in which case *p will blow up.
    sizeof is a language keyword, and not a function (it's an operator). Specifically,
    Quote Originally Posted by Standard, C89
    The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand, which is not itself evaluated. The result is an integer constant.
    sizeof(*p) will work as it should.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  13. #13
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > #define INT_SIZE 4
    Well if you did
    #define INT_SIZE sizeof(int)
    It would be better.

    > Unless p == NULL, in which case *p will blow up.
    The only 'dereference' is through the compiler's expression tree to find the type of *p, and thus work out the size of the required object. Nothing happens at run-time, except to multiply by the constant which the compiler determined to be the size of a *p
    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.

  14. #14
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Salem View Post
    > Unless p == NULL, in which case *p will blow up.
    The only 'dereference' is through the compiler's expression tree to find the type of *p, and thus work out the size of the required object. Nothing happens at run-time, except to multiply by the constant which the compiler determined to be the size of a *p
    Thanks, I'll have to test that and see, but it's good to know.

  15. #15
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Thanks, I'll have to test that and see, but it's good to know.
    If your test fails, then the compiler does not comply with both the C89 and C99 editions of the C standard.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 08:18 PM
  2. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM
  3. HUGE fps jump
    By DavidP in forum Game Programming
    Replies: 23
    Last Post: 07-01-2004, 10:36 AM
  4. C diamonds and perls :°)
    By Carlos in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 05-16-2003, 10:19 PM
  5. All u wanted to know about data types&more
    By SAMSAM in forum Windows Programming
    Replies: 6
    Last Post: 03-11-2003, 03:22 PM