Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan.Pop@cern.ch (Dan Pop)]

In <63toc4$baf@sun001.spd.dsccc.com> jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes:

>In article <danpop.878857889@news.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote:
>)In <63r2sv$rgm$1@helios.crest.nt.com> kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>)
>)>In article <63qkp9$bqr$3@darla.visi.com>,
>)>Peter Seebach <seebs@plethora.net> wrote:
>)>>
>)>>No.  Short is not required to be any smaller than long, nor any larger
>)>>than char.  A system where all four types are 64-bits is conforming.
>)>
>)>But it cannot be a conforming hosted implementation, as I pointed out
>)>in the other article, because the getc() and putc() functions require
>)>the int type to represent everything in the range of 0 to UCHAR_MAX,
>)>plus the extra value EOF. It therefore follows that a hosted implementation
>)>requires the additional requirement:
>)>
>)>    char < int
>)
>)How did you get the idea that EOF must be an "extra value"?  The standard
>)only requires it to be negative, not to be different from ANY value 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>)returned by a successful call to getc().
>
>It's true that EOF does not have to be an "extra value". However, it
>-is- required to be -negative-.

Exactly what I wrote above, so I can't see your point here.

>Further, there seems to be an implicit
>requirement that an int can represent any value which an "unsigned char"
>can represent (see 7.3). If one takes the wording
>
>	In all cases the argument is an int, the value of which shall be
>	representable as an unsigned char or shall equal the value of
>	the macro EOF.
>
>as meaning that the values representable as unsigned char is a subset of
>the values representable as an int, then I think that it follows that
>it is a -proper- subset.

Your interpretation is plain wrong.  This paragraph says that the int
argument passed to the function shall be representable as un unsigned 
char and nothing more.  An implementation with sizeof(int) == 1 definitely
satisfies this requirement.

>That would seem to imply that sizeof int > sizeof char.

Nope.

More relevant to the discussion are the integral promotions:

    A char, a short int, or an int bit-field, or their signed or
    unsigned varieties, or an object that has enumeration type, may be
    used in an expression wherever an int or unsigned int may be used.  If
    an int can represent all values of the original type, the value is
    converted to an int; otherwise it is converted to an unsigned int.

The wording here definitely provides support for the situation when an
unsigned char cannot be represented as a signed int, right?

Dan
--
Dan Pop
CERN, IT Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland