Thread: size of an integer pointer

  1. #1
    Registered User
    Join Date
    Mar 2007
    Posts
    25

    size of an integer pointer

    I have a simple code here

    Code:
    int i, *p;
    printf("sizeof i =%d, size of pointer =%d", sizeof(int), sizeof(p));
    I get 4 bytes for size of int & 8 bytes for size of pointer.

    Usually we get 4 bytes for any pointer size.

    Please comment

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Usually we get 4 bytes for any pointer size.
    Usually... on 32 bit systems. If you are on a 64 bit system, 8 byte pointers are more likely.
    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

  3. #3
    Registered User
    Join Date
    Mar 2007
    Posts
    25
    in that case(64 bit processor) should not we get 8 bytes for sizeof(int) also?

  4. #4
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    No.
    Quote Originally Posted by http://home.att.net/~jackklein/c/inttypes.html
    An int was originally intended to be the "natural" word size of the processor. Many modern processors can handle different word sizes with equal ease.

    It is int which causes the greatest confusion. Some people are certain that an int has 16 bits and sizeof(int) is 2. Others are equally sure that an int has 32 bits and sizeof(int) is 4.

    Who is right? On any given compiler, one or the other could be right. On some compilers, both would be wrong.
    See limits.h for values.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by onebrother View Post
    in that case(64 bit processor) should not we get 8 bytes for sizeof(int) also?
    As explained, not necessarily.

    "int" is a "natural integer" to the processor. On for example x86-64, handling 32-bit integers is "natural" to the processor - it is in fact often 1 byte shorter in machine code to do 32-bit operations than 64-bit operations. Further, since MOST of the time, 32-bit integers are entirely sufficient for the calculations where "int" is being used, it serves no real purpose to extend the integer type to 64-bit - the integers would just take up twice as much space without any real benefit to anything or anyone (and form slightly bigger code to make it worse). It is also worth noting that the x86-64 architecture automatically extends 32-bit math operations so that the result is consistant throughout the 64 bits, e.g. subtracting one from zero will form a 64-bit value of -1, even if it's done in 32-bit math.

    In a 64-bit machine where accessing 32-bit integers would be significantly slower/generate noticeably more code or otherwise cause performance problems, then choosing int as 64-bit would definitely make sense.

    The C standard makes no real guarantees about the size of int - it has a minimum size (I think of being able to hold -32768 .. 32767), but there's no statement of it's maximum size. long int must not be SMALLER than int, but can be the same.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    it has a minimum size (I think of being able to hold -32768 .. 32767)
    I think it's from -32767 to +32767, to accommodate both ones' and twos' complement.

    Case in point: this is a 64-bit machine, and it has 4-byte ints and 8-byte longs. Here's my limits.h.
    Code:
    /* Copyright (C) 1991, 1992, 1996, 1997, 1998, 1999, 2000, 2005
       Free Software Foundation, Inc.
       This file is part of the GNU C Library.
    
       The GNU C Library is free software; you can redistribute it and/or
       modify it under the terms of the GNU Lesser General Public
       License as published by the Free Software Foundation; either
       version 2.1 of the License, or (at your option) any later version.
    
       The GNU C Library is distributed in the hope that it will be useful,
       but WITHOUT ANY WARRANTY; without even the implied warranty of
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
       Lesser General Public License for more details.
    
       You should have received a copy of the GNU Lesser General Public
       License along with the GNU C Library; if not, write to the Free
       Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
       02111-1307 USA.  */
    
    /*
     *      ISO C99 Standard: 7.10/5.2.4.2.1 Sizes of integer types <limits.h>
     */
    
    #ifndef _LIBC_LIMITS_H_
    #define _LIBC_LIMITS_H_ 1
    
    #include <features.h>
    
    
    /* Maximum length of any multibyte character in any locale.
       We define this value here since the gcc header does not define
       the correct value.  */
    #define MB_LEN_MAX      16
    
    
    /* If we are not using GNU CC we have to define all the symbols ourself.
       Otherwise use gcc's definitions (see below).  */
    #if !defined __GNUC__ || __GNUC__ < 2
    
    /* We only protect from multiple inclusion here, because all the other
       #include's protect themselves, and in GCC 2 we may #include_next through
       multiple copies of this file before we get to GCC's.  */
    # ifndef _LIMITS_H
    #  define _LIMITS_H     1
    
    #include <bits/wordsize.h>
    
    /* We don't have #include_next.
       Define ANSI <limits.h> for standard 32-bit words.  */
    
    /* These assume 8-bit `char's, 16-bit `short int's,
       and 32-bit `int's and `long int's.  */
    
    /* Number of bits in a `char'.  */
    #  define CHAR_BIT      8
    
    /* Minimum and maximum values a `signed char' can hold.  */
    #  define SCHAR_MIN     (-128)
    #  define SCHAR_MAX     127
    
    /* Maximum value an `unsigned char' can hold.  (Minimum is 0.)  */
    #  define UCHAR_MAX     255
    
    /* Minimum and maximum values a `char' can hold.  */
    #  ifdef __CHAR_UNSIGNED__
    #   define CHAR_MIN     0
    #   define CHAR_MAX     UCHAR_MAX
    #  else
    #   define CHAR_MIN     SCHAR_MIN
    #   define CHAR_MAX     SCHAR_MAX
    #  endif
    
    /* Minimum and maximum values a `signed short int' can hold.  */
    #  define SHRT_MIN      (-32768)
    #  define SHRT_MAX      32767
    
    /* Maximum value an `unsigned short int' can hold.  (Minimum is 0.)  */
    #  define USHRT_MAX     65535
    
    /* Minimum and maximum values a `signed int' can hold.  */
    #  define INT_MIN       (-INT_MAX - 1)
    #  define INT_MAX       2147483647
    
    /* Maximum value an `unsigned int' can hold.  (Minimum is 0.)  */
    #  define UINT_MAX      4294967295U
    
    /* Minimum and maximum values a `signed long int' can hold.  */
    #  if __WORDSIZE == 64
    #   define LONG_MAX     9223372036854775807L
    #  else
    #   define LONG_MAX     2147483647L
    #  endif
    #  define LONG_MIN      (-LONG_MAX - 1L)
    
    /* Maximum value an `unsigned long int' can hold.  (Minimum is 0.)  */
    #  if __WORDSIZE == 64
    #   define ULONG_MAX    18446744073709551615UL
    #  else
    #   define ULONG_MAX    4294967295UL
    #  endif
    
    #  ifdef __USE_ISOC99
    
    /* Minimum and maximum values a `signed long long int' can hold.  */
    #   define LLONG_MAX    9223372036854775807LL
    #   define LLONG_MIN    (-LLONG_MAX - 1LL)
    
    /* Maximum value an `unsigned long long int' can hold.  (Minimum is 0.)  */
    #   define ULLONG_MAX   18446744073709551615ULL
    
    #  endif /* ISO C99 */
    
    # endif /* limits.h  */
    #endif  /* GCC 2.  */
    
    #endif  /* !_LIBC_LIMITS_H_ */
    
     /* Get the compiler's limits.h, which defines almost all the ISO constants.
    
        We put this #include_next outside the double inclusion check because
        it should be possible to include this file more than once and still get
        the definitions from gcc's header.  */
    #if defined __GNUC__ && !defined _GCC_LIMITS_H_
    /* `_GCC_LIMITS_H_' is what GCC's file defines.  */
    # include_next <limits.h>
    #endif
    
    /* The <limits.h> files in some gcc versions don't define LLONG_MIN,
       LLONG_MAX, and ULLONG_MAX.  Instead only the values gcc defined for
       ages are available.  */
    #if defined __USE_ISOC99 && defined __GNUC__
    # ifndef LLONG_MIN
    #  define LLONG_MIN     (-LLONG_MAX-1)
    # endif
    # ifndef LLONG_MAX
    #  define LLONG_MAX     __LONG_LONG_MAX__
    # endif
    # ifndef ULLONG_MAX
    #  define ULLONG_MAX    (LLONG_MAX * 2ULL + 1)
    # endif
    #endif
    
    #ifdef  __USE_POSIX
    /* POSIX adds things to <limits.h>.  */
    # include <bits/posix1_lim.h>
    #endif
    
    #ifdef  __USE_POSIX2
    # include <bits/posix2_lim.h>
    #endif
    
    #ifdef  __USE_XOPEN
    # include <bits/xopen_lim.h>
    #endif
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. stack and pointer problem
    By ramaadhitia in forum C Programming
    Replies: 2
    Last Post: 09-11-2006, 11:41 PM
  2. Pointer Size Relative To Integers?
    By SMurf in forum C Programming
    Replies: 1
    Last Post: 04-18-2006, 06:58 AM
  3. Direct3D problem
    By cboard_member in forum Game Programming
    Replies: 10
    Last Post: 04-09-2006, 03:36 AM
  4. Invalid conversion from 'void*' to 'BYTE' help
    By bikr692002 in forum C++ Programming
    Replies: 9
    Last Post: 02-22-2006, 11:27 AM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM