What Defins the "C" Language?

[Chris Croughton]

What ranges are those? Where are they specified? This statement contradicts
H&S: "The C language does not specify the range of integers that the
integral types will represent...".

Section 5.2.4.2 in the C99 spec. gives the minimum ranges that a
conforming implementation must support, in the form of the minimum
values for the macros in limits.h. The C89 spec. had something similar.
There are no upper bounds on the magnitudes representable by each type,
however (so for instance an unsigned char is at least 8 bits but could
be 9, 12, 32 or more). There is also a relationship such that:

bits(char) <= bits(short) <= bits(int) <= bits(long) <= bits(long long)

(bits(<t>) meaning the number of significant bits in type <t>) and the
same for unsigned types (e.g. you can't have a char which can't be
represented in a short or a long with fewer bits than an int, although
they could all be the same size and are for some processors).

Chris C

 

[Mike Wahler]

What about a 62-bit byte? MPJ

Perfectly valid for C.

-Mike

 

[CBFalconer]

.... snip ...

Prexactly.

I seem to recall conversations in years past of old machines that
had strange integer sizes (9 bits?) which C would support. Am I
delusional?

Which is why the existance of limits.h is prescribed, so that the
user can know the exact characteristics of the system on which he
is running.

 

[CBFalconer]

Merrill & Michele wrote:
.... snip ...


Your point was... ? Do you want to encourage/contradict/... the OP?

I am getting rather tired of his snide remarks, which appear to be
largely for the purpose of hearing himself.

 

[CBFalconer]

What ranges are those? Where are they specified? This statement
contradicts H&S: "The C language does not specify the range of
integers that the integral types will represent...".

Just #include <limits.h> in your program, and all the critical

From N869:

5.2.4.2 Numerical limits

[#1] A conforming implementation shall document all the
limits specified in this subclause, which are specified in
the headers <limits.h> and <float.h>. Additional limits are
specified in <stdint.h>.

5.2.4.2.1 Sizes of integer types <limits.h>

[#1] The values given below shall be replaced by constant
expressions suitable for use in #if preprocessing
directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
the following shall be replaced by expressions that have the
same type as would an expression that is an object of the
corresponding type converted according to the integer
promotions. Their implementation-defined values shall be
equal or greater in magnitude (absolute value) to those
shown, with the same sign.

-- number of bits for smallest object that is not a bit-
field (byte)
CHAR_BIT 8

-- minimum value for an object of type signed char
SCHAR_MIN -127 // -(27-1)

-- maximum value for an object of type signed char
SCHAR_MAX +127 // 27-1

-- maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28-1

-- minimum value for an object of type char
CHAR_MIN see below

-- maximum value for an object of type char
CHAR_MAX see below

-- maximum number of bytes in a multibyte character, for
any supported locale
MB_LEN_MAX 1

-- minimum value for an object of type short int
SHRT_MIN -32767 // -(215-1)

-- maximum value for an object of type short int
SHRT_MAX +32767 // 215-1

..... and so on ....

 

[Default User]

Randy Yates wrote:

What ranges are those? Where are they specified? This statement
contradicts H&S: "The C language does not specify the range of
integers that the integral types will represent...".

It doesn't specifies exact ranges. It specifies a minimal range. The
standard says something like (from N869):

``plain'' int object has the natural size suggested by the
architecture of the execution environment (large enough to
contain any value in the range INT_MIN to INT_MAX as defined
in the header <limits.h>).

The actual range is up to the implementation, as long as it satisfies
the requirement above.



Brian

 

[Goran Larsson]

Last time I checked, signed char was an integer type. Ditto about
unsigned char:

I wrote that nine bit was not enough for integer types such as short,
int and long. I never wrote that these three integer types were the
only integer types available. It was just a list of a few integer types
that requires more than nine bits.

 

[Randy Yates]

No, it does not contradict H&S: the (exact) ranges are not specified, but
"minimum" (ie smallest absolute value) ranges are.

We're getting into semantic issues. I take the statement "the ranges
are not specified" to mean that they are free to assume any value. They are
not.

 

[Joona I Palaste]

We're getting into semantic issues. I take the statement "the ranges
are not specified" to mean that they are free to assume any value. They are
not.

I don't see what is the problem. The ISO C standard specifies the
minimum requirements for the ranges, i.e. the largest possible lower
bound and the smallest possible upper bound. The implementation is then
free to specify any specific range it wants to, as long as it keeps
within these requirements. Isn't this what everyone has been saying all
along?

 

[Randy Yates]

I don't see what is the problem. The ISO C standard specifies the
minimum requirements for the ranges, i.e. the largest possible lower
bound and the smallest possible upper bound. The implementation is then
free to specify any specific range it wants to, as long as it keeps
within these requirements. Isn't this what everyone has been saying all
along?

No. Once again, H&S say

The C language does not specify the range of integers that the
integral types will represent...".

That statement is not correct. The correct statement would be

The C language partially specifies the range of integers that the
integral types will represent by establishing minimums for those
ranges. The actual ranges are implementation-defined subject to
these minimum range constraints.

 

[Merrill & Michele]

"Mike Wahler" >

Perfectly valid for C.

No argument there. I just think there needs to be something said advocating
the width of a byte in bits as the order of a Boolean algebra. MPJ

 

[Tim Rentsch]

This is where you went wrong. See below.

I don't see what is the problem. The ISO C standard specifies the
minimum requirements for the ranges, i.e. the largest possible lower
bound and the smallest possible upper bound. The implementation is then
free to specify any specific range it wants to, as long as it keeps
within these requirements. Isn't this what everyone has been saying all
along?

No. Once again, H&S say

The C language does not specify the range of integers that the
integral types will represent...".

That statement is not correct. [...snip...]

The online Merriam Websters dictionary gives this definition for
specify:

to name or state explicitly or in detail

Clearly the standard doesn't do that. The C language *constrains* the
ranges of integers that integral types may represent, but it does not
*specify* the range of integers that integral types will represent.

 

[Erik Trulsson]

I thought I had, by the paragraphs I cited and you repeated below:


Yes, that is how I interpreted the statements.


How could it be otherwise? First the authors state that the language
does not specify the range of integers, then they state that ISO C
requires a minimum width, implying a minimum range. The two statements
can't be both true for the same standard.

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

 

[Randy Yates]

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

An architect is designing a house for you. She asks you, "How large shall
I make the master bedroom." You reply, "I leave it unspecified." So she
makes it 10x15. Then you say, "That's too small."

Better to follow the advice of Quintilian:

One should not aim at being possible to understand, but at being
impossible to misunderstand.

--RY

--
% Randy Yates % "How's life on earth?
%% Fuquay-Varina, NC % ... What is it worth?"
%%% 919-577-9882 % 'Mission (A World Record)',
%%%% <[email protected]> % *A New World Record*, ELO
http://home.earthlink.net/~yatescr

 

[Richard Tobin]

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

The first paragraph says that the *only* thing the C language
specifies about the range of integers is that short <= int <= long.
The second says that ISO C specifies short >= 16, int >= 16, long >= 32.

Taken literally and separately, the two paragraphs are inconsistent
if "the C language" == "ISO C".

I don't have the book so I don't know whether they're really meant to
be taken separately like that. But it's now clear why the OP saw a
contradiction.

-- Richard

 

[Keith Thompson]

In Harbison and Steele's text (fourth edition, p.111)
it is stated,

The C language does not specify the range of integers that the
integral types will represent, except ot say that type int may not
be smaller than short and long may not be smaller than int.

They go on to say,

Many implementations represent characters in 8 bits, type short in
16 bits, and type long in 32 bits, with type int using either 16 or
32 bits depending on the implementation. ISO C requires
implementations to use at least these widths.

If the C language is not defined by ISO C, then what defines it?

The C language is defined by the ISO standard. It is not defined by
H&S, though it's a very good reference. In this case, I think that
paragraph in the 4th edition was poorly worded. There's no power
struggle between H&S and ISO, just a mistake.

The corresponding paragraph in the 5th edition says:

Standard C specifies the minimum precision for most integer types.
Type char must be at least 8 bits wide, type short at least 16
bits wide, type long at least 32 bits wide, and type long long at
least 64 bits wide. (That is, C99 requires 64-bit integer types
and the full set of 64-bit arithmetic operations.) The actual
ranges of the integer types are recorded in limits.h.

The error in H&S4 may date back to K&R1 (1978, pre-ISO), which doesn't
require specific minimum ranges. All the examples shown in K&R1
satisfy the ISO minima, but a system with 6-bit char, 12-bit short and
int, and 24-bit long would have been legal.

The intent is that short and long should provide different lengths
of integers where practical; int will normally reflect the most
"natural" size for a particular machine. As you can see, each
compiler is free to interpret short and long as appropriate for
its own hardware. About all you should count on is that short is
no longer than long.

-- K&R1 2.2, page 34

C89/C90 imposed the stricter requirements we enjoy today.

 

[Jack Klein]

No. Once again, H&S say

The C language does not specify the range of integers that the
integral types will represent...".

That statement is not correct. The correct statement would be

The C language partially specifies the range of integers that the
integral types will represent by establishing minimums for those
ranges. The actual ranges are implementation-defined subject to
these minimum range constraints.

Several people have explained to you what the C language does specify.
Apparently you think that the wording of the first phrase you quoted
from H&S is incorrect. That is not a problem for either the C
language or the C standard.

If you don't like their wording, why don't you take it up with them
and stop quibbling over a non-language issue here?

 

[Keith Thompson]

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

Sure, but look at the statement in H&S 4ed:

The C language does not specify the range of integers that the
integral types will represent, except to say that type int may not
be smaller than short and long may not be smaller than int.

This clearly (and incorrectly) states that the short<=int and
int<=long restrictions are the only thing the language specifies about
the ranges of the integral types. In fact, the standard specifies
these restrictions *plus* certain minimum ranges. The rest of the
paragraph mentions that ISO C specifies minima, contradicting the
initial statement.

It's a mistake in the 4th edition, corrected in the 5th edition.
It's not a huge deal, and it's not worth going through contortions to
demonstrate that their statement is consistent with the standard.

 

[Randy Yates]

The C language is defined by the ISO standard. It is not defined by
H&S, though it's a very good reference. In this case, I think that
paragraph in the 4th edition was poorly worded. There's no power
struggle between H&S and ISO, just a mistake.

The corresponding paragraph in the 5th edition says:

Standard C specifies the minimum precision for most integer types.
Type char must be at least 8 bits wide, type short at least 16
bits wide, type long at least 32 bits wide, and type long long at
least 64 bits wide. (That is, C99 requires 64-bit integer types
and the full set of 64-bit arithmetic operations.) The actual
ranges of the integer types are recorded in limits.h.

The error in H&S4 may date back to K&R1 (1978, pre-ISO), which doesn't
require specific minimum ranges. All the examples shown in K&R1
satisfy the ISO minima, but a system with 6-bit char, 12-bit short and
int, and 24-bit long would have been legal.

The intent is that short and long should provide different lengths
of integers where practical; int will normally reflect the most
"natural" size for a particular machine. As you can see, each
compiler is free to interpret short and long as appropriate for
its own hardware. About all you should count on is that short is
no longer than long.

-- K&R1 2.2, page 34

C89/C90 imposed the stricter requirements we enjoy today.

Thanks for this excellent historical summary and answer to my
question, Keith.
--
% Randy Yates % "Rollin' and riding and slippin' and
%% Fuquay-Varina, NC % sliding, it's magic."
%%% 919-577-9882 %
%%%% <[email protected]> % 'Living' Thing', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

 

[Randy Yates]

[...]
Several people have explained to you what the C language does specify.
Apparently you think that the wording of the first phrase you quoted
from H&S is incorrect. That is not a problem for either the C
language or the C standard.

If you don't like their wording, why don't you take it up with them
and stop quibbling over a non-language issue here?

Jack,

This is not only a question of H&S's wording, nor of what the ISO
standard says, but also of what actually defines the language, now and
in the past. This has not at all been clearly explained to my
satisfaction by anyone until Keith's recent post.

In my opinion, such matters are far from a quibble and clearly on-topic.
--
% Randy Yates % "My Shangri-la has gone away, fading like
%% Fuquay-Varina, NC % the Beatles on 'Hey Jude'"
%%% 919-577-9882 %
%%%% <[email protected]> % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr