Direct computation of integer limits in K&R2?

[Ioannis Vranos]

C95:

Since sizeof(N)= sizeof(signed N)= sizeof(unsigned N)

where N can be char, short, int, long


and as you mentioned they use the same amount of storage, how can

INT_MIN be equal to -INT_MAX since the range of values is the same.

 

[Richard Heathfield]

Ioannis Vranos said:

INT_MIN be equal to -INT_MAX since the range of values is the same.

Sign-and-magnitude representation.

 

[CBFalconer]

.... snip ...


It must participate in other bit operations, though, like ~, &,
| and ^. Even so,I can't see any way to avoid UB when trying to
calculate the range of int. Equally, I don't have a persuasive
argument that it *can't* be done, either.

Totally unnecessary. All those integral max values are specified
in <limits.h>. That's why.

 

[Dik T. Winter]

> Micah Cowan wrote, On 12/03/08 05:55:
>

>
> It's easy to forget. I'm not actually aware of any implementations which
> make use of this freedom.

(Sign bit 1 other bits 0 is a trap representation.) Some Gould machines
did it, or were it the Modcomps? I disremember and do not have the manuals
here, but one of the two.

 

[pete]

Peter Nilsson said:


I don't think it can.

It can.

sizeof(int) == 2
sizeof(unsigned) == 2
CHAR_BIT == 16
INT_MAX == 0xffff
UINT_MAX == 0xffff

 

[Richard Heathfield]

pete said:

It can.

sizeof(int) == 2
sizeof(unsigned) == 2
CHAR_BIT == 16
INT_MAX == 0xffff
UINT_MAX == 0xffff

"The range of nonnegative values of a signed integer type is a subrange of
the corresponding unsigned integer type, and the representation of the
same value in each type is the same."

Since, in your example, int has 16 value bits, and since there must also be
a sign bit, that makes 17 bits altogether that contribute to the value. I
could be wrong, of course, but doesn't that mean that unsigned int must
also have 17 bits that contribute to the value?

 

[pete]

pete said:


"The range of nonnegative values
of a signed integer type is a subrange of
the corresponding unsigned integer type,
and the representation of the
same value in each type is the same."

That's exactly what I've shown.

Since, in your example, int has 16 value bits,
and since there must also be a sign bit,
that makes 17 bits altogether that contribute to the value. I
could be wrong, of course,
but doesn't that mean that unsigned int must
also have 17 bits that contribute to the value?

You're mixing terms.

"value bits" != "bits that contribute to the value"

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).


Your claim implies that you believe that M can't equal N.

 

[Richard Heathfield]

pete said:

(if there are M value bits in the signed type
and N in the unsigned type, then M<=N).


Your claim implies that you believe that M can't equal N.

I sit corrected. Thank you.

 

[Ioannis Vranos]

You're mixing terms.

"value bits" != "bits that contribute to the value"

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).


Your claim implies that you believe that M can't equal N.

What is N869? My answer as C95 based. Actually since it is an exercise
of K&R2, it is a C90 question.

 

[Ioannis Vranos]

Hello all,

In K&R2 one exercise asks the reader to compute and print the limits for
the basic integer types. This is trivial for unsigned types. But is it
possible for signed types without invoking undefined behaviour
triggered by overflow? Remember that the constants in limits.h cannot
be used.

Can you mention the chapter of K&R2 where this exercise is?

 

[ymuntyan]

You're mixing terms.

"value bits" != "bits that contribute to the value"

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).

Your claim implies that you believe that M can't equal N.

What is N869? My answer as C95 based. Actually since it is an exercise
of K&R2, it is a C90 question.

Does C90 guarantee absence of padding bits? I didn't find
anything like that (though I didn't try hard because this
question is about C standard history, not about pathologies
permitted by the C standard).

The quoted text is from C99, N869 is a C99 draft, and
the C90 text (quoted by Richard) is still true in C99.

Yevgen

 

[user923005]

Can you mention the chapter of K&R2 where this exercise is?

Exercise 2.1, page 36

 

[santosh]

(e-mail address removed) wrote:

Does C90 guarantee absence of padding bits? I didn't find
anything like that (though I didn't try hard because this
question is about C standard history, not about pathologies
permitted by the C standard).

C90 doesn't seem to mention padding bits. But is that equivalent to not
allowing them?

The quoted text is from C99, N869 is a C99 draft, and
the C90 text (quoted by Richard) is still true in C99.

Yes. A draft of C89 is available in the clc-wiki site, formerly hosted
by Dan Pop.

 

[Richard]

(e-mail address removed) wrote:



C90 doesn't seem to mention padding bits. But is that equivalent to not
allowing them?


Yes. A draft of C89 is available in the clc-wiki site, formerly hosted
by Dan Pop.

Take a point for gratuitous name dropping there Santosh :-;

 

[CBFalconer]

.... snip ...

What is N869? My answer as C95 based. Actually since it is an
exercise of K&R2, it is a C90 question.

It is the last draft of C99 before publication, and the last
version available in text form. You can get one organized for
quoting, grepping, etc. bzip2 compressed at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

 

[Ioannis Vranos]

Exercise 2.1, page 36

I have not the English text but a local-language translated book, so I
translate the exercise in English here (if anyone can post the English
version of this K&R2 exercise, it will be great):


Translated:

Exercise 2-1. Write a program to determine the value ranges of the
variable types char, short, int, and long, both for signed and the
unsigned ones, displaying the appropriate values from the standard
headers, and by direct calculation. And something more difficult, if you
attempt to calculate it: determine the value ranges of the various
floating-point types.

 

[Ioannis Vranos]

Translated:

Exercise 2-1. Write a program to determine the value ranges of the
variable types char, short, int, and long, both for signed and the
unsigned ones, displaying the appropriate values from the standard
headers, and by direct calculation. And something more difficult, if you
attempt to calculate it: determine the value ranges of the various
floating-point types.

I think as it is spelled above we can get some flexibility. I think by
displaying the integer min and max values from limits.h, we can use this
information to determine how these types are implemented.

What do you think?

 

[Richard Heathfield]

Ioannis Vranos said:

I have not the English text but a local-language translated book, so I
translate the exercise in English here (if anyone can post the English
version of this K&R2 exercise, it will be great):


Translated:

Exercise 2-1. Write a program to determine the value ranges of the
variable types char, short, int, and long, both for signed and the
unsigned ones, displaying the appropriate values from the standard
headers, and by direct calculation. And something more difficult, if you
attempt to calculate it: determine the value ranges of the various
floating-point types.

Original:

Exercise 2-1. Write a program to determine the ranges of char, short, int,
and long, both signed and unsigned, by printing appropriate values from
standard headers and by direct computation. Harder if you compute them:
determine the ranges of the various floating-point types.

 

[santosh]

I think as it is spelled above we can get some flexibility. I think by
displaying the integer min and max values from limits.h, we can use
this information to determine how these types are implemented.

What do you think?

Perhaps, but that's a bit of a cheat, IMO.

In any case how do you propose to use the min. and max. values in
limits.h to work out the integer representation?

 

[CBFalconer]

I have not the English text but a local-language translated book,
so I translate the exercise in English here (if anyone can post
the English version of this K&R2 exercise, it will be great):

Translated:

Exercise 2-1. Write a program to determine the value ranges of the
variable types char, short, int, and long, both for signed and the
unsigned ones, displaying the appropriate values from the standard
headers, and by direct calculation. And something more difficult,
if you attempt to calculate it: determine the value ranges of the
various floating-point types.

Basically, just #include <limits.h>. Other for floats.