Minimum sizes of integral and floating point types

I

Ioannis Vranos

About C95.

Is there any mentioning in the standard about the number of usable bits
of the various built in types, apart from char/signed char/unsigned char
types? Or only about the minimum value ranges of them?
 
J

jacob navia

Ioannis said:
About C95.

Is there any mentioning in the standard about the number of usable bits
of the various built in types, apart from char/signed char/unsigned char
types? Or only about the minimum value ranges of them?

1) C95 is not a standard. It is obsoleted by C99.

2) Use C99 int32_t, int64_t, etc
 
B

Ben Pfaff

Ioannis Vranos said:
Is there any mentioning in the standard about the number of usable
bits of the various built in types, apart from char/signed
char/unsigned char types? Or only about the minimum value ranges of
them?

I am not sure exactly what you are after. If you want the number
of bits in a given type, including any sign and padding bits,
then CHAR_BIT*sizeof(type) will give you the answer. If you want
the number of value bits, then you can figure it out from the
type's range, although the calculation for that is not as simple.
 
I

Ioannis Vranos

Ben said:
I am not sure exactly what you are after. If you want the number
of bits in a given type, including any sign and padding bits,
then CHAR_BIT*sizeof(type) will give you the answer. If you want
the number of value bits, then you can figure it out from the
type's range, although the calculation for that is not as simple.


In other words my question is this. Does C95 specify that long must be
at least 32 bits, or it only provides the minimum value ranges?
 
K

Keith Thompson

Ioannis Vranos said:
In other words my question is this. Does C95 specify that long must be
at least 32 bits, or it only provides the minimum value ranges?

In C95 (or C89/C90), just as in C99, the predefined integral types are
defined in terms of their minimal ranges. The range of long is at
least -2147483647 .. +2147483647, which implies that it must have a
least 32 bits (1 sign bit and at least 31 value bits). I don't think
C95 uses the concepts of "value bits" and "padding bits"; those were
introduced by C99.
 
K

Keith Thompson

jacob navia said:
1) C95 is not a standard. It is obsoleted by C99.

It is still a de facto standard, far more widely implemented than C99.

This attitude is amusing coming from someone whose own compiler
doesn't fully implement the C99 standard.
2) Use C99 int32_t, int64_t, etc

How does that answer his question? He was asking how the standard
defines the built-in types, not how to obtain a type with a specified
number of bits. And of course int32_t and int64_t are, at least in
principle, not portable; if the implementation doesn't happen to
provide type of exactly 32 or 64 bits with a 2's-complement
representation and no padding bits, they won't exist.
 
B

Barry Schwarz

About C95.

Is there any mentioning in the standard about the number of usable bits
of the various built in types, apart from char/signed char/unsigned char
types? Or only about the minimum value ranges of them?

For integer types you can compute the minimum number of usable bits
from the ranges. For floating point types, you can compute the
minimum number of usable bits from the minimum number of significant
digits in each type.


Remove del for email
 
S

santosh

Ioannis said:
What do you mean it isn't a standard? Of course it is.

Techinally the current C Standard is ISO 9899:1999, also called C99.

However, in practise, C95 (the Standard ISO:9899:1989 + Amendment 1) is
more widely implemented and used.
I want to program in C95.

Perfectly fine.

Coming to your question, the Standard actually defines the fundamental
types in terms of their range, i.e., a signed char must hold values
from -127 to 127, an unsigned long must hold values from 0 to
4294967295 and so on. These details can be found in section 5.2.4.2 of
the Standard.

Only the types intN_t and uintN_t for values of N 8, 16, 32, and 64 are
more rigorously defined. They must be exactly of that size (in bits)
and must be represented in twos complement and must not have padding
bits. But they are not relevant to you, as you are focused on C95.

Although you can find out the number of usable (i.e. value) bits from
the range of a type, it's not easy and even then there is no
information on particular bits. For example bits 2 to 4 may be padding
bits, or may not be, you can't easily tell.
 
R

Richard Heathfield

Ioannis Vranos said:
What do you mean it isn't a standard? Of course it is.

Right.

Do you remember your first foray into comp.lang.c a few years ago? Remember
when you knew all the answers, and anyone that disagreed with you must be
some kind of idiot? Well, you learned better. Jacob Navia didn't.
I want to program in C95.

I want to program in C, which for me means sticking to the common subset of
C90, C95, and C99. It is true that the current de jure standard is C99,
but until, at the very least, GNU and Microsoft offer conforming C99
implementations it will not be a de facto standard in the foreseeable
future. Note that lcc-win32, which Jacob Navia pushes even harder than he
pushes C99, is not C99-conforming.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,992
Messages
2,570,220
Members
46,805
Latest member
ClydeHeld1

Latest Threads

Top