Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > FAQ issue: Guaranteed value ranges of fundamental types?

Reply
Thread Tools

FAQ issue: Guaranteed value ranges of fundamental types?

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      02-05-2005
The C++ FAQ item 29.5 (this seems to be strongly related to C), at
<url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
mentions that

<quote>
C++ guarantees a char is exactly one byte which is at least 8 bits, short
is at least 16 bits, int is at least 16 bits, and long is at least 32
bits.
</quote>


Questions:

(1) This guarantee seems to come from the C standard. Which I don't
have. Does the C++ standard really guarantee this?

(2) Is this guarantee originally formulated in terms of number of bits,
or in terms of e.g. decimal value ranges?

(3) Concerning (2), if formulated in terms of number of bits, are the number
of bits mentioned simply sizeof(T)*CHAR_BIT, which doesn't say much about
value ranges, or are they stated to be the value representation bits?


(Intentionally cross-posted [comp.lang.c++] and [comp.lang.c]).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      02-05-2005
Alf P. Steinbach wrote:
>
> The C++ FAQ item 29.5 (this seems to be strongly related to C), at
> <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
> mentions that
>
> <quote>
> C++ guarantees a char is exactly
> one byte which is at least 8 bits, short
> is at least 16 bits, int is at least 16 bits,
> and long is at least 32 bits.
> </quote>
>
> Questions:
>
> (1) This guarantee seems to come from the C standard. Which I don't
> have. Does the C++ standard really guarantee this?
>
> (2) Is this guarantee originally
> formulated in terms of number of bits,
> or in terms of e.g. decimal value ranges?


The part of the C standard which is called
"Sizes of integral types" in C89 and
"Sizes of integer types" in C99,
is specified in terms of ranges.

C99 describes padding bits for integer types.

--
pete
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      02-05-2005
"Alf P. Steinbach" wrote:
>
> The C++ FAQ item 29.5 (this seems to be strongly related to C), at
> <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
> mentions that
>
> <quote>
> C++ guarantees a char is exactly one byte which is at least 8
> bits, short is at least 16 bits, int is at least 16 bits, and
> long is at least 32 bits.
> </quote>
>
> Questions:
>
> (1) This guarantee seems to come from the C standard. Which I
> don't have. Does the C++ standard really guarantee this?


I dunno. This is c.l.c. Google for N869 to get the last draft of
the C standard. f'ups set, which you should have done in the
original posting.

>
> (2) Is this guarantee originally formulated in terms of number of
> bits, or in terms of e.g. decimal value ranges?


By values. Other specifications translate that into viable bits.

>
> (3) Concerning (2), if formulated in terms of number of bits, are
> the number of bits mentioned simply sizeof(T)*CHAR_BIT, which
> doesn't say much about value ranges, or are they stated to be
> the value representation bits?


No, because there may be bits for other purposes, such as trap
values.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson


 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      02-05-2005
* CBFalconer:
> "Alf P. Steinbach" wrote:
> >
> > The C++ FAQ item 29.5 (this seems to be strongly related to C), at
> > <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
> > mentions that
> >
> > <quote>
> > C++ guarantees a char is exactly one byte which is at least 8
> > bits, short is at least 16 bits, int is at least 16 bits, and
> > long is at least 32 bits.
> > </quote>
> >
> > Questions:
> >
> > (1) This guarantee seems to come from the C standard. Which I
> > don't have. Does the C++ standard really guarantee this?

>
> I dunno. This is c.l.c. Google for N869 to get the last draft of
> the C standard. f'ups set, which you should have done in the
> original posting.


It was intentionally cross-posted; F.U.T. overridden.

Thanks for the "N869" reference.

Yes, the C standard specifies those minimum ranges in the documentation
of [limits.h], which the C++ standard refers to the C standard for.


> > (2) Is this guarantee originally formulated in terms of number of
> > bits, or in terms of e.g. decimal value ranges?

>
> By values. Other specifications translate that into viable bits.


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      02-05-2005
Alf P. Steinbach wrote:

> The C++ FAQ item 29.5 (this seems to be strongly related to C), at
> <url: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.5>
> mentions that
>
> <quote>
> C++ guarantees a char is exactly one byte which is at least 8 bits, short
> is at least 16 bits, int is at least 16 bits, and long is at least 32
> bits.
> </quote>
>
>
> Questions:
>
> (1) This guarantee seems to come from the C standard. Which I don't
> have. Does the C++ standard really guarantee this?



Yes. Also, except where otherwise is stated, C90 is a subset of C++98
standard.



> (2) Is this guarantee originally formulated in terms of number of bits,
> or in terms of e.g. decimal value ranges?



Decimal ranges. C90 defines the following (from the last C90 draft):


"Sizes of integral types <limits.h>

The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Their
implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.

* maximum 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

* maximum value for an object of type signed char
SCHAR_MAX +127

* maximum value for an object of type unsigned char
UCHAR_MAX 255

* 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

* maximum value for an object of type short int
SHRT_MAX +32767

* maximum value for an object of type unsigned short int
USHRT_MAX 65535

* minimum value for an object of type int
INT_MIN -32767

* maximum value for an object of type int
INT_MAX +32767

* maximum value for an object of type unsigned int
UINT_MAX 65535

* minimum value for an object of type long int
LONG_MIN -2147483647

* maximum value for an object of type long int
LONG_MAX +2147483647

* maximum value for an object of type unsigned long int
ULONG_MAX 4294967295


If the value of an object of type char sign-extends when used in
an expression, the value of CHAR_MIN shall be the same as that of
SCHAR_MIN and the value of CHAR_MAX shall be the same as that of
SCHAR_MAX . If the value of an object of type char does not sign-extend
when used in an expression, the value of CHAR_MIN shall be 0 and the
value of CHAR_MAX shall be the same as that of UCHAR_MAX./7/"




> (3) Concerning (2), if formulated in terms of number of bits, are the number
> of bits mentioned simply sizeof(T)*CHAR_BIT, which doesn't say much about
> value ranges, or are they stated to be the value representation bits?



Apart from char, and unsigned char that are guaranteed to not have
padding bits (anyone may tell about signed char?), the number of bits
of a type may contain padding bits etc.




--
Ioannis Vranos

http://www23.brinkster.com/noicys
 
Reply With Quote
 
Andreas Huber
Guest
Posts: n/a
 
      02-05-2005
Alf P. Steinbach wrote:
[snip]
> short is at least 16 bits, int is at least 16 bits, and long
> is at least 32 bits.
> </quote>


That is contrary to what my copy of the standard says (see 3.9.1/1). It
basically says that char <= short <= int <= long (i.e. there is no
guarantee that a long is any bigger than a char, although there probably
is no platform where sizeof(long) == sizeof(char)). For more information
see 5.3.3 and 1.7..

Regards,

--
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header.

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-05-2005
"Andreas Huber" <(E-Mail Removed)> wrote...
> Alf P. Steinbach wrote:
> [snip]
>> short is at least 16 bits, int is at least 16 bits, and long
>> is at least 32 bits.
>> </quote>

>
> That is contrary to what my copy of the standard says (see 3.9.1/1). It
> basically says that char <= short <= int <= long (i.e. there is no


I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
derive that 'char <= short <= int'. But that doesn't matter. You are
actually correct, the C standard defined those relationships between
type sizes. It is true that char <= short <= int. It does not, however,
mean that there is no guarantee that 'int' is larger than 'char'. The
same C90 Standard when describing <limits.h> (and see 18.2.2/2 to know
that C++ mandates the same values for all xx_MAX and xx_MIN values),
does require *at least* ranges -32767..32767 for 'int' and -2^31..2^31
for 'long'.

> guarantee that a long is any bigger than a char, although there probably
> is no platform where sizeof(long) == sizeof(char)). For more information
> see 5.3.3 and 1.7..


For more information see 18.2.2

V


 
Reply With Quote
 
infobahn
Guest
Posts: n/a
 
      02-05-2005
Victor Bazarov wrote:
>
> I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
> derive that 'char <= short <= int'. But that doesn't matter. You are
> actually correct, the C standard defined those relationships between
> type sizes.


C&V please.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      02-05-2005
"infobahn" <(E-Mail Removed)> wrote...
> Victor Bazarov wrote:
>>
>> I wonder what _exactly_ does your copy say in 3.9.1/1 that makes you
>> derive that 'char <= short <= int'. But that doesn't matter. You are
>> actually correct, the C standard defined those relationships between
>> type sizes.

>
> C&V please.


I don't have a copy of C90. I used to have a printed copy at work,
but I don't work there any longer. I can be mistaken, therefore.

V


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-05-2005
"Andreas Huber" <(E-Mail Removed)> writes:
> Alf P. Steinbach wrote:
> [snip]
>> short is at least 16 bits, int is at least 16 bits, and long
>> is at least 32 bits.
>> </quote>

>
> That is contrary to what my copy of the standard says (see
> 3.9.1/1). It basically says that char <= short <= int <= long
> (i.e. there is no guarantee that a long is any bigger than a char,
> although there probably is no platform where sizeof(long) ==
> sizeof(char)). For more information see 5.3.3 and 1.7..


There's no contradiction.

The C standard guarantees that short and int are at least 16 bits, and
long is at least 32 bits (it states these in terms of minimum ranges,
but the requirement for a binary representation implies the sizes
given). It also guarantees that int as at least as wide as short, and
long is at least as wide as int. (Padding bits mean that this applies
to the ranges, not the sizes.)

I think the C++ standard has the same guarantees.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(guaranteed?) default value of an unresolved external Alfonso Morra C Programming 4 08-22-2005 02:57 PM
fundamental question on process Praveen VHDL 3 04-24-2005 10:33 PM
FAQ issue: Guaranteed value ranges of fundamental types? Alf P. Steinbach C Programming 30 02-14-2005 09:46 AM
FUNDAMENTAL QUESTION 1: Gary Java 3 11-29-2003 05:34 PM
Is the storage for a std::vector<T> guaranteed to be contiguous? (from FAQ) Newsgroup - Ann C++ 0 08-15-2003 01:42 AM



Advertisments