minimum and maximum values of an object of type int

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Sep 14, 2007.

  1. Guest

    Guys,

    Does the standard allow to an implementation to chose any maximum
    and minimum value for an object of type int ?

    For eg. Can an implementation with sizeof(int)=4, chose to have value
    of
    INT_MAX = 2147483646 (in limits.h).

    Or it is mandatory that if sizeof(int)=4, then the INT_MAX should have
    to be
    equal to 2147483647 and INT_MIN should have to be equal to (-
    INT_MAX-1).

    Again, thanks a lot for any help.
     
    , Sep 14, 2007
    #1
    1. Advertising

  2. said:

    > Guys,
    >
    > Does the standard allow to an implementation to chose any maximum
    > and minimum value for an object of type int ?


    No.

    Let's first deal with the minimal range.

    INT_MIN must be at most -32767 (but can be lower - or, if you prefer,
    may have a higher absolute value, but must still be negative). INT_MAX
    must be at least 32767 (but can be higher).

    Now let's deal with this:

    > For eg. Can an implementation with sizeof(int)=4, chose to have value
    > of
    > INT_MAX = 2147483646 (in limits.h).


    No. An int must comprise one sign bit, at least fifteen value bits (but
    more are allowed), and 0 or more "padding bits". INT_MAX must therefore
    be exactly one less than a power of two. INT_MIN must be negative, of
    course, but its absolute value might reasonably be a power of two (the
    same power as for INT_MAX), or one less than that power of two. Thus,
    if there are fifteen value bits, INT_MIN must be -32767 or -32768.

    > Or it is mandatory that if sizeof(int)=4, then the INT_MAX should have
    > to be
    > equal to 2147483647 and INT_MIN should have to be equal to (-
    > INT_MAX-1).


    No, because padding bits contribute to the size of the int. Thus, it is
    possible, where CHAR_BIT is 8 and sizeof(int) is 4, for there to be
    anywhere from 0 to 16 padding bits, and thus INT_MIN could be anything
    from -32767 to -2147483648. Under the same constraints, INT_MAX could
    be anything from 32767 to 2147483647.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Sep 14, 2007
    #2
    1. Advertising

  3. Guest

    On Sep 14, 3:31 pm, Richard Heathfield <> wrote:
    > said:
    >
    > > Guys,

    >
    > > Does the standard allow to an implementation to chose any maximum
    > > and minimum value for an object of type int ?

    >
    > No.
    >
    > Let's first deal with the minimal range.
    >
    > INT_MIN must be at most -32767 (but can be lower - or, if you prefer,
    > may have a higher absolute value, but must still be negative). INT_MAX
    > must be at least 32767 (but can be higher).
    >
    > Now let's deal with this:
    >
    > > For eg. Can an implementation with sizeof(int)=4, chose to have value
    > > of
    > > INT_MAX = 2147483646 (in limits.h).

    >
    > No. An int must comprise one sign bit, at least fifteen value bits (but
    > more are allowed), and 0 or more "padding bits". INT_MAX must therefore
    > be exactly one less than a power of two. INT_MIN must be negative, of
    > course, but its absolute value might reasonably be a power of two (the
    > same power as for INT_MAX), or one less than that power of two. Thus,
    > if there are fifteen value bits, INT_MIN must be -32767 or -32768.
    >
    > > Or it is mandatory that if sizeof(int)=4, then the INT_MAX should have
    > > to be
    > > equal to 2147483647 and INT_MIN should have to be equal to (-
    > > INT_MAX-1).

    >
    > No, because padding bits contribute to the size of the int. Thus, it is
    > possible, where CHAR_BIT is 8 and sizeof(int) is 4, for there to be
    > anywhere from 0 to 16 padding bits, and thus INT_MIN could be anything
    > from -32767 to -2147483648. Under the same constraints, INT_MAX could
    > be anything from 32767 to 2147483647.
    >


    Thanks Richard for your reply.
    So, if the implementation (with int = 4bytes = 32 bits) chose +32767
    as the highest value, does that mean all the
    values from +32768 to +2147483647 are trap representation
    on this implementation ?
     
    , Sep 14, 2007
    #3
  4. said:

    <snip>

    > So, if the implementation (with int = 4bytes = 32 bits) chose +32767
    > as the highest value, does that mean all the
    > values from +32768 to +2147483647 are trap representation
    > on this implementation ?


    Not necessarily, but AIUI it *could* mean that, yes.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Sep 14, 2007
    #4
  5. On Sep 14, 1:24 pm, ""
    <> wrote:

    > Thanks Richard for your reply.
    > So, if the implementation (with int = 4bytes = 32 bits) chose +32767
    > as the highest value, does that mean all the
    > values from +32768 to +2147483647 are trap representation
    > on this implementation ?


    Not quite. The way you described it, you have 16 padding bits. If you
    store lets say 32767 into an int value, you will have a sign bit that
    is set to zero, fifteen value bits all set to 1, and 16 padding bits
    set to some value that the implementation thinks is right. For
    example, the padding bits could be all zero, or they could be copies
    if the sign bit and the value bits.

    By accessing the four bytes of the int using an unsigned char*, you
    may be able to figure out which bits are sign bit, value bits and
    padding bits (For example, this would work in an implementation where
    the padding bits are always zero; if the padding bits are always
    copies of other bits, you can't find out which are padding bits). If
    you know the padding bits, you could modify padding bits by accessing
    the int using an unsigned char*.

    The implementation defines what happens: If the implementation says
    that there are no trap representations, then storing anything into the
    padding bits is legal and doesn't change the value. You store 32767
    into an int, change the padding bits any way you like, and the value
    in the int is still 32767. On the other hand, the implementation could
    say that any setting of the padding bits other than the one it prefers
    is a trap representation. Again, store 32767, change the padding bits,
    try reading the int, and you get undefined behaviour.

    Anyway, the way you wrote it is quite imprecise. You couldn't store a
    value of 32768 into an int because there is no such value. You could
    say something like "Whenever I store a value from -32768 to 32767, the
    representation of the result is the same as on my other computer which
    uses a PowerPC processor with INT_MIN/MAX = -2^31, 2^31-1. What
    happens if I create a representation that looks like 32768 looks on my
    other computer?", but there is no such value as 32768.
     
    christian.bau, Sep 14, 2007
    #5
  6. "christian.bau" <> a écrit dans le message
    de news: ...
    > On Sep 14, 1:24 pm, ""
    > <> wrote:
    >
    >> Thanks Richard for your reply.
    >> So, if the implementation (with int = 4bytes = 32 bits) chose +32767
    >> as the highest value, does that mean all the
    >> values from +32768 to +2147483647 are trap representation
    >> on this implementation ?

    >
    > Not quite. The way you described it, you have 16 padding bits. If you
    > store lets say 32767 into an int value, you will have a sign bit that
    > is set to zero, fifteen value bits all set to 1, and 16 padding bits
    > set to some value that the implementation thinks is right. For
    > example, the padding bits could be all zero, or they could be copies
    > if the sign bit and the value bits.
    >
    > By accessing the four bytes of the int using an unsigned char*, you
    > may be able to figure out which bits are sign bit, value bits and
    > padding bits (For example, this would work in an implementation where
    > the padding bits are always zero; if the padding bits are always
    > copies of other bits, you can't find out which are padding bits). If
    > you know the padding bits, you could modify padding bits by accessing
    > the int using an unsigned char*.
    >
    > The implementation defines what happens: If the implementation says
    > that there are no trap representations, then storing anything into the
    > padding bits is legal and doesn't change the value. You store 32767
    > into an int, change the padding bits any way you like, and the value
    > in the int is still 32767. On the other hand, the implementation could
    > say that any setting of the padding bits other than the one it prefers
    > is a trap representation. Again, store 32767, change the padding bits,
    > try reading the int, and you get undefined behaviour.
    >
    > Anyway, the way you wrote it is quite imprecise. You couldn't store a
    > value of 32768 into an int because there is no such value. You could
    > say something like "Whenever I store a value from -32768 to 32767, the
    > representation of the result is the same as on my other computer which
    > uses a PowerPC processor with INT_MIN/MAX = -2^31, 2^31-1. What
    > happens if I create a representation that looks like 32768 looks on my
    > other computer?", but there is no such value as 32768.
    >


    And now let's get practical: can someone share with us an actual encounter
    of such things as padding bits and trap values, preferably within this
    century ?

    --
    Chqrlie.
     
    Charlie Gordon, Sep 14, 2007
    #6
  7. On Sep 14, 11:36 pm, "Charlie Gordon" <> wrote:
    > "christian.bau" <> a écrit dans le message
    > denews: 1189793897.754500.39__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$...
    >
    >
    >
    > > On Sep 14, 1:24 pm, ""
    > > <> wrote:

    >
    > >> Thanks Richard for your reply.
    > >> So, if the implementation (with int = 4bytes = 32 bits) chose +32767
    > >> as the highest value, does that mean all the
    > >> values from +32768 to +2147483647 are trap representation
    > >> on this implementation ?

    >
    > > Not quite. The way you described it, you have 16 padding bits. If you
    > > store lets say 32767 into an int value, you will have a sign bit that
    > > is set to zero, fifteen value bits all set to 1, and 16 padding bits
    > > set to some value that the implementation thinks is right. For
    > > example, the padding bits could be all zero, or they could be copies
    > > if the sign bit and the value bits.

    >
    > > By accessing the four bytes of the int using an unsigned char*, you
    > > may be able to figure out which bits are sign bit, value bits and
    > > padding bits (For example, this would work in an implementation where
    > > the padding bits are always zero; if the padding bits are always
    > > copies of other bits, you can't find out which are padding bits). If
    > > you know the padding bits, you could modify padding bits by accessing
    > > the int using an unsigned char*.

    >
    > > The implementation defines what happens: If the implementation says
    > > that there are no trap representations, then storing anything into the
    > > padding bits is legal and doesn't change the value. You store 32767
    > > into an int, change the padding bits any way you like, and the value
    > > in the int is still 32767. On the other hand, the implementation could
    > > say that any setting of the padding bits other than the one it prefers
    > > is a trap representation. Again, store 32767, change the padding bits,
    > > try reading the int, and you get undefined behaviour.

    >
    > > Anyway, the way you wrote it is quite imprecise. You couldn't store a
    > > value of 32768 into an int because there is no such value. You could
    > > say something like "Whenever I store a value from -32768 to 32767, the
    > > representation of the result is the same as on my other computer which
    > > uses a PowerPC processor with INT_MIN/MAX = -2^31, 2^31-1. What
    > > happens if I create a representation that looks like 32768 looks on my
    > > other computer?", but there is no such value as 32768.

    >
    > And now let's get practical: can someone share with us an actual encounter
    > of such things as padding bits and trap values, preferably within this
    > century ?


    There are some TI processors that support 40 bit integer arithmetic,
    using pairs of two 32 bit registers. int = 32 bit, but long = 40 bit
    stored in eight bytes. And padding bits in floating-point numbers are
    quite common; the compiler that I mostly use has sizeof (long double)
    = 16, and long double uses 80 bits.
     
    christian.bau, Sep 15, 2007
    #7
  8. "christian.bau" <> writes:
    > On Sep 14, 11:36 pm, "Charlie Gordon" <> wrote:

    [...]
    >> And now let's get practical: can someone share with us an actual encounter
    >> of such things as padding bits and trap values, preferably within this
    >> century ?

    >
    > There are some TI processors that support 40 bit integer arithmetic,
    > using pairs of two 32 bit registers. int = 32 bit, but long = 40 bit
    > stored in eight bytes. And padding bits in floating-point numbers are
    > quite common; the compiler that I mostly use has sizeof (long double)
    > = 16, and long double uses 80 bits.


    Floating-point types don't have "padding bits" in the sense defined in
    the standard (beause the standard doesn't specify enough about
    floating-point representations for the concept to be necessary).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 16, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Schnoffos
    Replies:
    2
    Views:
    1,252
    Martien Verbruggen
    Jun 27, 2003
  2. Hal Styli
    Replies:
    14
    Views:
    1,713
    Old Wolf
    Jan 20, 2004
  3. Replies:
    8
    Views:
    825
    Ben Bacarisse
    Oct 19, 2008
  4. Pugi!
    Replies:
    2
    Views:
    117
    Steve
    Feb 12, 2007
  5. Marco
    Replies:
    2
    Views:
    125
    Serhiy Storchaka
    Jul 16, 2013
Loading...

Share This Page