Classification of arithmetic types

Discussion in 'C Programming' started by jacob navia, Dec 11, 2006.

  1. jacob navia

    jacob navia Guest

    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
    jacob navia, Dec 11, 2006
    #1
    1. Advertising

  2. jacob navia

    Eric Sosman Guest

    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.h> types?

    > 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
    lid
    Eric Sosman, Dec 11, 2006
    #2
    1. Advertising

  3. jacob navia

    jacob navia Guest

    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.h> types?
    > 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, Dec 11, 2006
    #3
  4. jacob navia

    jacob navia Guest

    jacob navia a écrit :
    > The same applies to chart ("plain" char)
    >


    Not "chart" but "char" of course. Excuse me.
    jacob navia, Dec 11, 2006
    #4
  5. jacob navia

    Richard Bos Guest

    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.h> types?
    > > 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
    Richard Bos, Dec 11, 2006
    #5
  6. jacob navia

    Eric Sosman Guest

    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.h> types?
    >> 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
    lid
    Eric Sosman, Dec 11, 2006
    #6
  7. jacob navia

    P.J. Plauger Guest

    "Eric Sosman" <> wrote in message
    news:...

    > 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.h> types?
    >
    >> 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
    P.J. Plauger, Dec 11, 2006
    #7
  8. jacob navia

    jacob navia Guest

    P.J. Plauger a écrit :
    > "Eric Sosman" <> wrote in message
    > news:...
    >
    >
    >>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.h> types?
    >>
    >>
    >>> 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
    jacob navia, Dec 11, 2006
    #8
  9. jacob navia <> writes:
    > 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.h> types?
    >> 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 "enumeration" 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_Keith) <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, Dec 11, 2006
    #9
  10. (Richard Bos) writes:
    > 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.h> types?
    >> > 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_Keith) <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, Dec 11, 2006
    #10
  11. jacob navia <> writes:
    [...]
    > 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?


    You don't get to define "arithmetic types". The term is defined in
    C99 6.2.5p18. (I believe your definition happens to match the
    standard's definition.)

    Read C99 6.2.5 before you speculate.

    --
    Keith Thompson (The_Other_Keith) <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, Dec 11, 2006
    #11
  12. jacob navia

    jacob navia Guest

    Keith Thompson a écrit :
    > jacob navia <> writes:
    > [...]
    >
    >>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?

    >
    >
    > You don't get to define "arithmetic types". The term is defined in
    > C99 6.2.5p18. (I believe your definition happens to match the
    > standard's definition.)
    >
    > Read C99 6.2.5 before you speculate.
    >


    The standard just says:

    "Integer and floating types are collectively called arithmetic types."

    This definition is just an enumeration, not a functional
    definition, that I would prefer.

    But this is not very important since the end result is the same.
    jacob navia, Dec 11, 2006
    #12
  13. jacob navia

    jacob navia Guest

    Keith Thompson a écrit :
    > jacob navia <> writes:
    >
    >>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.


    Mmmmm

    " char is distinct from both signed char and unsigned char,
    though it has the same characteristics as one of them" ...

    I have some difficulty following you here. If it has the same
    characteristics then is the same! How can a type
    have the same characteristics (and name) and still be different?

    long and int are different types since long can be longer than int,
    even if in many implementations long == int. OK.

    But char can never have a different size than one of the
    signed/unsigned char types so IT IS the same...

    > 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?)


    Dunno. Char is signed by default.
    jacob navia, Dec 11, 2006
    #13
  14. jacob navia wrote:
    > Keith Thompson a écrit :
    > > jacob navia <> writes:
    > >
    > >>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.

    >
    > Mmmmm
    >
    > " char is distinct from both signed char and unsigned char,
    > though it has the same characteristics as one of them" ...
    >
    > I have some difficulty following you here. If it has the same
    > characteristics then is the same! How can a type
    > have the same characteristics (and name) and still be different?


    #include <limits.h>

    #if CHAR_MIN < 0
    typedef signed char plain_char;
    #else
    typedef unsigned char plain_char;
    #endif

    plain_char *a;
    /* really plain */ char *b;

    int main(void) {
    a = b; /* disallowed */
    b = a; /* disallowed */
    }

    If char were the same type as (un)signed char, this would be allowed.
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=, Dec 11, 2006
    #14
  15. jacob navia

    P.J. Plauger Guest

    "jacob navia" <> wrote in message
    news:...

    > Keith Thompson a écrit :
    >> jacob navia <> writes:
    >>
    >>>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.

    >
    > Mmmmm
    >
    > " char is distinct from both signed char and unsigned char,
    > though it has the same characteristics as one of them" ...
    >
    > I have some difficulty following you here. If it has the same
    > characteristics then is the same! How can a type
    > have the same characteristics (and name) and still be different?


    The proper term, instead of "characteristics", is "representation".
    It is often true in C that two types have the same representation
    but are nevertheless considered by the compiler to be distinct
    types. char/signed char or char/unsigned char is just one of these
    pairs.

    > long and int are different types since long can be longer than int,
    > even if in many implementations long == int. OK.
    >
    > But char can never have a different size than one of the
    > signed/unsigned char types so IT IS the same...


    The same representation, yes.

    >> 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?)

    >
    > Dunno. Char is signed by default.


    Sez who?

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Dec 11, 2006
    #15
  16. jacob navia

    P.J. Plauger Guest

    "jacob navia" <> wrote in message
    news:457d8792$0$25906$...

    > P.J. Plauger a écrit :
    >> "Eric Sosman" <> wrote in message
    >> news:...
    >>
    >>
    >>>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.h> types?
    >>>
    >>>
    >>>> 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.


    We don't include the language portion of P&B in our latest manual,
    since it's a pure library manual as much as possible. But you'll
    find descriptions of the constraints on:

    -- wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t, and the
    <stdint.h> types

    -- time_t, clock_t, wctrans_t, and wctype_t

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Dec 11, 2006
    #16
  17. jacob navia

    CBFalconer Guest

    Richard Bos wrote:
    > jacob navia <> wrote:
    >

    .... snip ...
    >>
    >> 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.


    As far as I am concerned, a 'type' means specifying the domain of
    allowable values, together with a set of operations on those
    values. C arithmetical types are extremely primitive, in that they
    cannot precisely specify the domain. They tend to simply specify a
    maximum (and minimum) value, which is pre-defined. This is one of
    the primary causes of invalid indices.

    Even an enum cannot specify the precise validity range in C. You
    can catch unenumerated values with a switch statement having a
    default case.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Dec 11, 2006
    #17
  18. jacob navia

    CBFalconer Guest

    Eric Sosman wrote:
    >

    .... snip ...
    >
    > 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."


    Reminds me of the arguments about type compatibility during Pascal
    standardization. It eventually became identical type names, rather
    than composition.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Dec 11, 2006
    #18
  19. On Mon, 11 Dec 2006 15:46:01 +0100, in comp.lang.c , jacob navia
    <> wrote:

    >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 fact the standard _doesn't_ say they have to be synonyms to any
    other type.

    For instance clock_t and time_t merely have to be arithmetic, so it
    could be a a 2560-bit double (7.23), irrespective of whether a long
    double were 32, 64, 80 or 128 bits. Size_t has to be an unsigned
    integer type - but again there's no restriction on width (7.17) so it
    could be wider than long long. In fact such designs might actually
    make sense - using an integer type for time _is_ kinda daft, while
    size_t needs to be able to refer to all possible availalbe memory..

    >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 C standard does explicitly say that its a distinct type
    (6.2.5p15).
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Dec 11, 2006
    #19
  20. jacob navia <> writes:
    > Keith Thompson a écrit :
    >> jacob navia <> writes:
    >>
    >>>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.

    >
    > Mmmmm
    >
    > " char is distinct from both signed char and unsigned char,
    > though it has the same characteristics as one of them" ...
    >
    > I have some difficulty following you here. If it has the same
    > characteristics then is the same!


    Um, no.

    > How can a type
    > have the same characteristics (and name) and still be different?


    By having the same characteristics (*not* the same name) and still
    being different. What's unclear about that?

    > long and int are different types since long can be longer than int,
    > even if in many implementations long == int. OK.


    Right, assuming that "long == int" is a shorthand for "long and int
    have the same range and size".

    int* and float* may very well have exactly the same characteristics
    (representation, alignment, etc.), but they're distinct types.

    long and int are distinct types even if they happen to have the same
    properties. It's exactly the same for char and signed char, and for
    char and unsigned char.

    > But char can never have a different size than one of the
    > signed/unsigned char types so IT IS the same...


    No, they're distinct types (that happen to have the same size). Are
    you arguing that size is the only thing that determines whether two
    types are the same? It isn't.

    C99 6.2.5p15:

    The three types char, signed char, and unsigned char are
    collectively called the _character types_. The implementation
    shall define char to have the same range, representation, and
    behavior as either signed char or unsigned char.

    with a footnote:

    CHAR_MIN, defined in <limits.h>, will have one of the values 0 or
    SCHAR_MIN, and this can be used to distinguish the two
    options. Irrespective of the choice made, char is a separate type
    from the other two and is not compatible with either.

    >> 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?)

    >
    > Dunno. Char is signed by default.


    Try compiling this:

    #include <limits.h>
    int main(void)
    {
    char *cp;
    unsigned char *up;
    signed char *sp;

    #if CHAR_MIN == 0
    /* plain char is unsigned */
    cp = up; /* constraint violation */
    #else
    /* plain char is signed */
    cp = sp; /* constraint violation */
    #endif
    return 0;
    }

    A conforming compiler must issue a diagnostic for whichever assignment
    is not deleted by the preprocessor. (If the diagnostic includes a
    line number, it will tell you whether plain char is signed or
    unsigned.) What does lcc-win32 do (in conforming mode)?

    --
    Keith Thompson (The_Other_Keith) <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, Dec 11, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Corn Holio

    Text Classification - Spam Filter

    Corn Holio, Jan 3, 2004, in forum: Java
    Replies:
    6
    Views:
    3,525
    Pavel Tonkov
    Jan 4, 2004
  2. Replies:
    1
    Views:
    562
    Paul Lutus
    Sep 8, 2004
  3. Stefan Ram
    Replies:
    4
    Views:
    453
    Chris Uppal
    Feb 1, 2006
  4. Internet Citizen

    Character classification: novice question

    Internet Citizen, May 14, 2004, in forum: C++
    Replies:
    2
    Views:
    457
    Internet Citizen
    May 14, 2004
  5. joshc
    Replies:
    5
    Views:
    539
    Keith Thompson
    Mar 31, 2005
Loading...

Share This Page