minimum and maximum values of an object of type int

[junky_fellow]

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.

[Richard Heathfield]

ju**********@yahoo.co.in 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

[junky_fellow]

On Sep 14, 3:31 pm, Richard Heathfield <[e-mail]:

[e-mail] 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 [phone] are trap representation
on this implementation ?

[Richard Heathfield]

ju**********@yahoo.co.in 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 [phone] 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

[christian.bau]

On Sep 14, 1:24 pm, "[e-mail]"
<[e-mail]:

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 [phone] 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.

[Charlie Gordon]

"christian.bau" <ch***********@cbau.wanadoo.co.uka écrit dans le message
de news: 11*********************@y42g2000hsy.googlegroups.c om...

On Sep 14, 1:24 pm, "[e-mail]"
<[e-mail]:

>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 [phone] 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.

[christian.bau]

On Sep 14, 11:36 pm, "Charlie Gordon" <[e-mail]:

"christian.bau" <[e-mail] écrit dans le message
denews: 1189793897.754500.39__BEGIN_MASK_n#9g02mG7!__...__ **********************@y42g2000hsy.googlegroups.co m...

On Sep 14, 1:24 pm, "[e-mail]"
<[e-mail]:

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 [phone] 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.

[Keith Thompson]

"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:

On Sep 14, 11:36 pm, "Charlie Gordon" <[e-mail]:

[...]

>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) ks***@mib.org <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"