From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,INVALID_MSGID, PLING_QUERY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public From: Dan.Pop@cern.ch (Dan Pop) Subject: Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Date: 1997/11/07 Message-ID: #1/1 X-Deja-AN: 287729045 Sender: news@news.cern.ch (USENET News System) X-Nntp-Posting-Host: ues5.cern.ch References: <34557f2b.1934172@news.mindspring.com> <63qkp9$bqr$3@darla.visi.com> <63r2sv$rgm$1@helios.crest.nt.com> <63toc4$baf@sun001.spd.dsccc.com> Organization: CERN European Lab for Particle Physics Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy,comp.lang.c,comp.lang.c++ Date: 1997-11-07T00:00:00+00:00 List-Id: In <63toc4$baf@sun001.spd.dsccc.com> jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes: >In article , Dan Pop 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 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