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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: kaz@helios.crest.nt.com (Kaz Kylheku) Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/04 Message-ID: <63p2g1$vnt$1@helios.crest.nt.com>#1/1 X-Deja-AN: 287126779 References: <345E3ACD.A15@gsg.eds.com> <878648818snz@genesis.demon.co.uk> <345F9728.D61@gsg.eds.com> Organization: A poorly-installed InterNetNews site Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-04T00:00:00+00:00 List-Id: In article <345F9728.D61@gsg.eds.com>, Shmuel (Seymour J.) Metz wrote: >Lawrence Kirby wrote: >> >> The portability implications of this are small or non-existent (there may >> be performace implications in rare circumstances, and issues relating to >> data sizes and external data formats). As ever the C language is designed >> with the assumption that the programmer knows what he is doing. The use >> of ranges implies that you know beforehand what those ranges will be. >> In C you follow a set of rules: >> >> 1. If the range is contained within -32767 to 32767 then you use int >> >> 2. If the range is contained within -2147483647 to 2147483647 then you >> use long. >> >> 3. If you want to minimise space usage (such as for array elements or >> structure members) and the range is contained within -32767 to 32767 then >> you can use short. For -127 to 127 you can use signed char. >> >> 4. The unsigned types have larger positive ranges if your range is >> non-negative. Notably unsigned char typically corresponds to the >> notion of "byte" in most languages. > >Those rules only apply if you are going from one 32-bit machine to >another; they have nothing to do with the definition of C itself and are >inapplicable when you have to move between different word sizes. > >The C standard makes the size of an int implimentation dependent, and on >16-bit machines it is normally 16. On 64-bit machines int is usually 64, >and if you want 32 you specify short. No C programmer who has a clue about portable coding would specify short to get a 32 bit type---unless he was worried about using the smallest possible type which fits, thus minimizing resource usage! Note that Lawrence mentions ``performance implications'' because he knows that if you follow the conservative rules, you might not necessarily use the machine's resources in the best way. This is true if that machine provides data types that have much larger ranges than what is minimally required. If you want a type that is at least 32 bits wide, you specify long or unsigned long. The language currently has no support for anything more. If you need 33 bits or more, there is no type which is guaranteed to satisfy. You either write code to emulate the greater precision, or you leave the realm of portable C coding and use some implementation-provided type like __longlong. A good C89 compiler for a 64+ bit platform should have a mode which flips longs back to 32 bits for compiling maximally portable programs that don't make use of the extra generosity. Look, if you find something factually wrong in a Lawrence Kirby posting, I shall promptly mail you a lollipop! :) -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton