Classification of arithmetic types

[jacob navia]

As Richard Bos rightly pointed out, I had left in my classification
of types the C99 types Complex and boolean. Here is a new
classification. Those are not mentioned in the classification
of Plauger and Brody, probably because their work predates
C99. Since there are no examples of this in the literature
(known to me) please take a look.

Thanks
3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 boolean type
3.1.1.1.1.2 char (signed/unsigned)
3.1.1.1.1.3 short (signed unsigned)
3.1.1.1.1.4 int (signed/unsigned)
3.1.1.1.1.5 long (signed/unsigned)
3.1.1.1.1.6 long long (signed/unsigned)
3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 Real types
3.1.1.2.1.1 float
3.1.1.2.1.2 double
3.1.1.2.1.3 long double
3.1.1.2.4 Complex types
3.1.1.2.4.1 float Complex
3.1.1.2.4.2 double Complex
3.1.1.2.4.2 long double Complex

I would define arithmetic types as those that define the 4 operations.
This distiguishes them from pointer types where addition and
subtraction are defined but not multiplication/division.

Is that correct?

jacob

[Eric Sosman]

jacob navia wrote:

As Richard Bos rightly pointed out, I had left in my classification
of types the C99 types Complex and boolean. Here is a new
classification. Those are not mentioned in the classification
of Plauger and Brody, probably because their work predates
C99. Since there are no examples of this in the literature
(known to me) please take a look.

Thanks
3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 boolean type
3.1.1.1.1.2 char (signed/unsigned)

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).

3.1.1.1.1.3 short (signed unsigned)
3.1.1.1.1.4 int (signed/unsigned)
3.1.1.1.1.5 long (signed/unsigned)
3.1.1.1.1.6 long long (signed/unsigned)

How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?

3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 Real types
3.1.1.2.1.1 float
3.1.1.2.1.2 double
3.1.1.2.1.3 long double

float_t and double_t?

3.1.1.2.4 Complex types
3.1.1.2.4.1 float Complex
3.1.1.2.4.2 double Complex
3.1.1.2.4.2 long double Complex

time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob navia]

Eric Sosman a écrit :

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).
How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?
time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.
For instance, in many implementations size_t is unsigned long,
or time_t is long long, or clock_t is int, etc etc.

They are derived types defined in terms of a more primitive type.

The same applies to chart ("plain" char) since it is defined either
as unsigned or signed char, what means it is not another basic
type but a synonym for one of the char types.

[jacob navia]

jacob navia a écrit :

The same applies to chart ("plain" char)

Not "chart" but "char" of course. Excuse me.

[Richard Bos]

jacob navia <ja***@jacob.re mcomp.frwrote:

Eric Sosman a écrit :

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).
How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?
time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.

Not necessarily. For example, on historic implementations , time_t was
often larger than a single long, and was therefore a struct. Ditto for,
e.g., fpos_t. The point about such types is that they may be one
specific primitive type on any particular implementation, but to the
wise C programmer they must remain abstract types. As such, they deserve
discussion.

Richard

[Eric Sosman]

jacob navia wrote:

Eric Sosman a écrit :

> Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).
How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?
time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.
For instance, in many implementations size_t is unsigned long,
or time_t is long long, or clock_t is int, etc etc.

"In many implementations " doesn't quite make the grade for
a treatise that is supposed to be about the language and not
about particular implementations of it. "In many implementations "
it is true that INT_MIN < -INT_MAX, but that's not true of the
language per se.

Even in C90 I'm not entirely sure that all the "named for a
purpose" types were required to be aliases of "ordinary" types as
opposed to implementation-defined "exotic" types. Certainly in
C99 the lid came off, and int_least16_t (for example) might not
be a synonym for any kind of char, short, or int.

The same applies to chart ("plain" char) since it is defined either
as unsigned or signed char, what means it is not another basic
type but a synonym for one of the char types.

The Standard disagrees with you (6.2.5/14). `char' is a
type unto itself, distinct from both `signed char' and
`unsigned char'. `int' and `short' are distinct types even
when both are 16 bits wide; `int' and `long' are distinct even
when both are 32 bits wide; `double' and `long double' are
distinct even when both are IEEE double-precision numbers.
Representation and behavior are not the sole ingredients of
"type."

--
Eric Sosman
es*****@acm-dot-org.invalid

[P.J. Plauger]

"Eric Sosman" <es*****@acm-dot-org.invalidwrot e in message
news:8o******** *************** *******@comcast .com...

jacob navia wrote:

>As Richard Bos rightly pointed out, I had left in my classification
of types the C99 types Complex and boolean. Here is a new
classification . Those are not mentioned in the classification
of Plauger and Brody, probably because their work predates
C99. Since there are no examples of this in the literature
(known to me) please take a look.

For an update of the Plauger & Brodie documentation, see the C
portion of our on-line manual:

http://www.dinkumware.com/manuals/

>3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 boolean type
3.1.1.1.1.2 char (signed/unsigned)

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).

> 3.1.1.1.1.3 short (signed unsigned)
3.1.1.1.1.4 int (signed/unsigned)
3.1.1.1.1.5 long (signed/unsigned)
3.1.1.1.1.6 long long (signed/unsigned)

How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?

> 3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 Real types
3.1.1.2.1.1 float
3.1.1.2.1.2 double
3.1.1.2.1.3 long double

float_t and double_t?

> 3.1.1.2.4 Complex types
3.1.1.2.4.1 float Complex
3.1.1.2.4.2 double Complex
3.1.1.2.4.2 long double Complex

time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

What the standard says about each of these types is summarized
in our manual.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[jacob navia]

P.J. Plauger a écrit :

"Eric Sosman" <es*****@acm-dot-org.invalidwrot e in message
news:8o******** *************** *******@comcast .com...

>>jacob navia wrote:

>>>As Richard Bos rightly pointed out, I had left in my classification
of types the C99 types Complex and boolean. Here is a new
classificati on. Those are not mentioned in the classification
of Plauger and Brody, probably because their work predates
C99. Since there are no examples of this in the literature
(known to me) please take a look.

For an update of the Plauger & Brodie documentation, see the C
portion of our on-line manual:

http://www.dinkumware.com/manuals/

>>>3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 boolean type
3.1.1.1.1.2 char (signed/unsigned)

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).

>> 3.1.1.1.1.3 short (signed unsigned)
3.1.1.1.1.4 int (signed/unsigned)
3.1.1.1.1.5 long (signed/unsigned)
3.1.1.1.1.6 long long (signed/unsigned)

How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?

>> 3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 Real types
3.1.1.2.1.1 float
3.1.1.2.1.2 double
3.1.1.2.1.3 long double

float_t and double_t?

>> 3.1.1.2.4 Complex types
3.1.1.2.4.1 float Complex
3.1.1.2.4.2 double Complex
3.1.1.2.4.2 long double Complex

time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

What the standard says about each of these types is summarized
in our manual.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Thanks for your answer Mr Plauger but I could not find that type
classification there. Maybe you would give a more specific link?
I browsed a lot of C stuff (and C++ stuff) but could not find it.

Thanks

[Keith Thompson]

jacob navia <ja***@jacob.re mcomp.frwrites:

Eric Sosman a écrit :

> Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).
How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?
time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.
For instance, in many implementations size_t is unsigned long,
or time_t is long long, or clock_t is int, etc etc.

They're typedefs for some predefined integer type, possible an
extended integer type (which you didn't mention).

Incidentally, be careful with the word "enumeratio n" in this context.

They are derived types defined in terms of a more primitive type.

No, the standard defines the term "derived type" (C99 6.2.5p20);
typedefs do not create derived types. If you're going to invent
terminology, be *very* careful to remain consistent with the standard.
Better yet, just use the standard's own terminology.

The same applies to chart ("plain" char) since it is defined either
as unsigned or signed char, what means it is not another basic
type but a synonym for one of the char types.

No, type char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them. This usually
doesn't matter due to implicit conversions, but these types:

char*
unsigned char*
signed char*

are all incompatible; values of these types cannot be assigned to each
other without a cast. If char were an alias for either signed char or
unsigned char, this would not be the case. (Does lcc-win32 get this
right?)

--
Keith Thompson (The_Other_Keit h) 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.

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

jacob navia <ja***@jacob.re mcomp.frwrote:

>Eric Sosman a écrit :

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).
How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.htype s?
time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.

Not necessarily. For example, on historic implementations , time_t was
often larger than a single long, and was therefore a struct. Ditto for,
e.g., fpos_t. The point about such types is that they may be one
specific primitive type on any particular implementation, but to the
wise C programmer they must remain abstract types. As such, they deserve
discussion.

Yes, but the standard specifically requires time_t to be an arithmetic
type (though there's not much you can do in portable code to take
advantage of this).

--
Keith Thompson (The_Other_Keit h) 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.