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=0.3 required=5.0 tests=BAYES_00,INVALID_MSGID, PLING_QUERY,REPLYTO_WITHOUT_TO_CC 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: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public From: fred@genesis.demon.co.uk (Lawrence Kirby) Subject: Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Date: 1997/11/05 Message-ID: <878763380snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 288134869 References: <34557f2b.1934172@news.mindspring.com> X-Mail2News-User: fred@genesis.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: genesis.demon.co.uk X-Trace: mail2news.demon.co.uk 878768009 17865 fred genesis.demon.co.uk Organization: none Reply-To: fred@genesis.demon.co.uk Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy Date: 1997-11-05T00:00:00+00:00 List-Id: In article nospam@spam.com writes: >kaz@helios.crest.nt.com (Kaz Kylheku) writes: > >> >> In article <345F49A2.5F5DC5A0@aom.ericsson.se>, >> Ted Lyngmo wrote: >> >Bob Horvath wrote: >> >> >> >> Hmmmm. How big is an int? >> > >> >As I've understood it, an int has two legal sizes. A short has only one, >> >> You haven't understood it. >> >> A short is large enough to represent numbers in the range -32767 to >> 32767. An int is also large enough to represent numbers in the >> same range. A long can represent numbers in the range -2147483647 >> to +2147483647. > >Nor have you. Strange, the requirements that Kaz has specified above are the requirements stated in the standard. Given that everything he stated is correct in what way did he misunderstand anything? Maybe you would be happier if "in the range" was replaced by "in at least the range". That makes it a bit clearer but doesn't change the meaning. >The definitions are as follows. > >short <= int <= long >short < long >short > char They may be your definitions but they aren't the definitions in the ANSI/ISO standard. Firstly you have to define what your comparisons refer to. The standard says nothing about the relative sizes of the types (in terms of space taken up) except that sizeof(char) is 1 and everything else is a multiple of that. The standard talks in terms of ranges and subranges. In the sequence signed char, short, int, long each type earlier in the list can represent a range of values that is a subrange of the types later on. Given your table refers to ranges and <= is a "subrange" operator then the first line is correct but incomplete and the other 2 are incorrect. The correct representation is: signed char <= short <= int <= long Note that this allows all types to have the same range and this does occur in practice (e.g. some C compilers for 32 bit DSPs do this). In addition to this each type is specified as having a minimum range of values that it must be able to represent, which Kaz correctly stated above. In summary: signed char: -127 to 127 short: -32767 to 32767 int: -32767 to 32767 long: -2147483647 to 2147483647 There are also corresponding unsigned types which have minimum ranges: unsigned char: 0 to 255 unsigned short: 0 to 65535 unsigned int: 0 to 65535 unsigned long: 0 to 4294967295 There is also char which the implementation is allowed to specify as having either the same range as signed char or the same as unsigned char. >If your system does not conform to this, it isn't ISO (I thinhk it was ISO) >compliant. I have a copy of the standard in front of me. Do you? If so have a look at sections 5.2.4.2.1 and 6.1.2.5. >What you stated above is true for (I would assume) all 32bit systems. It >will not necessarily hold for 64 bit or 128 bit systems. It holds for all conforming C implementations. >I even had one person in the past try and tell me that when Intel went to >64bits, that M$ was going to have: > > short = 2 bytes > long = 4 bytes > int = 8 bytes That would be possible but then the int would have to have unused bits ("holes", which the standard permits), which makes it rather pointless. int isn't allowed to represent a greater range than long. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------