Thread: Size of NULL

    #1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    35
    Rep Power
    2

    Size of NULL


    When I printed the size of NULL
    I got it as 8 in gcc comiler.
    Since the 0 is an integer and the size of 0 should be 4 right?
  2. #2
  3. Jealous Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,303
    Rep Power
    9400
    NULL is a pointer, not an integer. It has the value of zero because it is a pointer to 0x00000000.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    35
    Rep Power
    2
    So it's an integer pointer right?
    Then also it should be 4, why 8?
  6. #4
  7. Wiser? Not exactly.
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    May 2001
    Location
    Bonita Springs, FL
    Posts
    5,959
    Rep Power
    4035
    The size of a pointer depends on the build type. For a 32-bit build they are 4 bytes, a 64-bit build they are 8 bytes.
    Recycle your old CD's, don't just trash them



    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
  8. #5
  9. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,417
    Rep Power
    1871
    > So it's an integer pointer right?
    > Then also it should be 4, why 8?
    No.

    Type T (whether int, char, double, struct etc) are distinct from pointers to T (whether int*, char*, double*, struct* etc). The size of one has no bearing on the size of the other.

    C doesn't even require that every T* has the same size either.

    You wouldn't get very far if the size of a char pointer was just 1.

    See also
    http://c-faq.com/ptrs/index.html
    http://c-faq.com/null/index.html
    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
  10. #6
  11. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2012
    Location
    Iran
    Posts
    149
    Rep Power
    140
    Originally Posted by salem
    Type T (whether int, char, double, struct etc) are distinct from pointers to T (whether int*, char*, double*, struct* etc). The size of one has no bearing on the size of the other.
    I just read your comment. Thanks a lot for pointing this out. I didn't know this and I was thinking that it was actually a one-to-one corresponding between each type T and its pointer T* , that is, both require the same space in terms of bytes. I did the following test and I saw that in fact this is not true and I was wrong.

    The following test was run on a Linux system:

    - system: Linux Fedora Core 17 (X86_64)
    - kernel: 3.9.10-100.fc17.x86_64
    - GCC version: 4.7.2
    - Glibc verision: 2.15

    C Code:
    #include <stdio.h>
    #include <stdlib.h>
     
    struct article
    {
        char    *articleRef;
        char    *articleLabel;
    };
    typedef struct article *article_ptr_ty;
     
     
    int main(int argc, char *argv[])
    {
        printf("sizeof(int) = %lu \t sizeof(int *) = %lu\n",
                sizeof(int), sizeof(int *));
     
        printf("sizeof(unsigned) = %lu \t sizeof(unsigned *) = %lu\n",
                sizeof(unsigned), sizeof(unsigned *));
     
        printf("sizeof(char) = %lu \t sizeof(char *) = %lu\n",
                sizeof(char), sizeof(char *));
     
        printf("sizeof(float) = %lu \t sizeof(float *) = %lu\n",
                sizeof(float), sizeof(float *));
     
        printf("sizeof(double) = %lu \t sizeof(double *) = %lu\n",
                sizeof(double), sizeof(double *));
     
        printf("sizeof(struct article) = %lu \t sizeof(article_ptr_ty) = %lu\n",
                sizeof(struct article), sizeof(article_ptr_ty));
     
     
        return EXIT_SUCCESS;
    }

    And the output is
    Code:
    $ gcc -Wall testscript.c -o testscript
    $ ./testscript
    sizeof(int) = 4          sizeof(int *) = 8
    sizeof(unsigned) = 4     sizeof(unsigned *) = 8
    sizeof(char) = 1         sizeof(char *) = 8
    sizeof(float) = 4        sizeof(float *) = 8
    sizeof(double) = 8       sizeof(double *) = 8
    sizeof(struct article) = 16      sizeof(article_ptr_ty) = 8
    $
    So, as I understand (please correct me if I'm wrong) how many bytes are reserved for each type T and its pointer T* is a matter of system, more precisely, how the glibc installed on the system has been implemented and it therefore has nothing to do with the specification of the C programming language, am I right?
    Regards,
    Dariyoosh
  12. #7
  13. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,417
    Rep Power
    1871
    > how many bytes are reserved for each type T and its pointer T* is a matter of system
    The size of a pointer is very much determined by the system, to a large extent by the hardware address limits, and to some extent by the virtual memory system imposed by the OS.

    It's not a libc issue, since it's not a requirement to actually have a libc (or use the one you're given). If you're writing free-standing code, you have a lot of freedom to make your own rules.

    The size of a char is by definition always 1 (regardless of how many bits there are in a char), as every other data type is always an integer multiple of this.

    All the data types have a lower bound (in the standard) for the range of values they must support. This directly implies the minimum number of bits in each data type, and indirectly the number of bytes in a data type (the result you get from sizeof).

    For example, the standard only says things like
    CHAR_BIT must be at least 8
    sizeof(char) is 1
    The minimum range of an int is -32768 to 32767

    Comments on this post

    • dariyoosh agrees : Thanks!
    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. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    35
    Rep Power
    2
    Thanks bro.
    You and your prog explained a lot.
    But I do still have the doubt that,
    why all pointer shows 8 bytes?
    Since they are addresses it should be 4?
  16. #9
  17. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,417
    Rep Power
    1871
    > why all pointer shows 8 bytes?
    Because the test results came from a 64-bit machine
    - system: Linux Fedora Core 17 (X86_64)
    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
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2013
    Posts
    35
    Rep Power
    2
    Thanks bro.
    you are correct.
    Mine is a 64 bit machine.
    That's why it is 8.
    Thanks.
  20. #11
  21. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2012
    Location
    Iran
    Posts
    149
    Rep Power
    140
    Dear Salem,

    Thank you very much for your time and your help.

    Originally Posted by salem
    > It's not a libc issue, since it's not a requirement to actually have a libc (or use the one you're given). If you're writing free-standing code, you have a lot of freedom to make your own rules
    Interesting, I didn't know that. When I started learning C (while I was at the university), they tought the language on Linux platforme by using the GCC compiler. Since then, whenever I installed a new Linux distribution (most of the time Fedora/Redhat) the libc (or should I say glibc as it seems to me that this one is implemented by GNU for GNU operating systems) the libc was always there, and I always thought that it was a requirement and that was the library allowing to use standard/predefined C functions defined in <stdio.h>, <string.h>, <stdlib.h>, <math.h>, etc.
    Regards,
    Dariyoosh
  22. #12
  23. Wiser? Not exactly.
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    May 2001
    Location
    Bonita Springs, FL
    Posts
    5,959
    Rep Power
    4035
    Libc is used to communicate with the OS, but if you were say writing code for embedded hardware then you would not be using libc.

    For normal OS programming, you will pretty much always be relying on libc in some way or another, but it's not a requirement of C programming in general.

    Comments on this post

    • dariyoosh agrees
    Recycle your old CD's, don't just trash them



    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
  24. #13
  25. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2012
    Location
    Iran
    Posts
    149
    Rep Power
    140

    Thumbs up


    Originally Posted by kicken
    Libc is used to communicate with the OS, but if you were say writing code for embedded hardware then you would not be using libc.

    For normal OS programming, you will pretty much always be relying on libc in some way or another, but it's not a requirement of C programming in general.
    Ok, thanks a lot for this information.
    Regards,
    Dariyoosh

IMN logo majestic logo threadwatch logo seochat tools logo