Article View: comp.sys.powerpc
Article #19Re: 64-bit
From: Dan Pop
Date: Mon, 04 Dec 1995 13:39
Date: Mon, 04 Dec 1995 13:39
51 lines
2800 bytes
2800 bytes
In <49tu81$jcf@otis.netspace.net.au> reiter@netspace.net.au (Peter Moulder) writes: >Lawrence Kirby (fred@genesis.demon.co.uk) wrote: > >>These seem rather pointless (other than uint32). sint16 is to all intents and >>purposes equivalent to short. > >I suppose there may (in the future, perhaps) be a compiler on which short is >more than 16 bits; occasionally you do want something to be exactly n bits. But there is absolutely no guarantee that you can get such an object. I want an integer which is exactly 17 bits. How do I get one? > >>schar8 can't be anything other than signed char. > >A char is guaranteed to be a byte, large enough to hold a character of the >native character set. A byte is usually [but not always] 8 bits. Right, but irrelevant. If a signed char is not 8 bits, how else do you define the type "schar8"? >I confess I've never used a compiler where a short wasn't 16 bits and a >char 8; however, the standard does at least leave room for the suggested >types to be useful. Such compilers do exist, however, and not only as museum objects :-) The compiler for the TMS 320C40 processor has 32-bit char's and short's, the Cray compiler has 64-bit short's. > >>To use the language (or at least the standard library) effectively you >>ultimately need to know what the underlying type is. fprintf and fscanf >>conversion specifiers are the most clear example of this. > >One solution I've used in the past is to cast to or from a long. There can >still be problems with this, though. There is no solution for *scanf, apart from using an object of a known type and assigning its value later to the object of an unknown type. For *printf, casting to signed or unsigned long is guaranteed to work, as long as the real definition doesn't use a nonstandard type (e.g. long long). The classical example is printing the result produced by the sizeof operator: using %lu and casting to unsigned long is guaranteed to produce the correct result. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Technical Details
Message-ID:
<danpop.818084366@rscernix>Path:
arc1-ca.pugleaf.net!CERN.ch!rscernix!danpopReferences:
<MEISSNER.95Nov9091407@tiktok.cygnus.com> <47tbel$tta@rs18.hrz.th-darmstadt.de> <483pe6$aft@spool.cs.wisc.edu> <wkdrSOS00YUsM7OxBb@andrew.cmu.edu> <48bjig$rgj@inca01.inca.co.nz> <816741669snz@genesis.demon.co.uk> <49tu81$jcf@otis.netspace.net.au>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.powerpc,comp.lang.c Path: arc1-ca.pugleaf.net!CERN.ch!rscernix!danpop From: danpop@mail.cern.ch (Dan Pop) Subject: Re: 64-bit X-Nntp-Posting-Host: ues5.cern.ch Message-ID: <danpop.818084366@rscernix> Sender: news@news.cern.ch (USENET News System) Organization: CERN European Lab for Particle Physics X-Newsreader: NN version 6.5.0 #7 (NOV) References: <MEISSNER.95Nov9091407@tiktok.cygnus.com> <47tbel$tta@rs18.hrz.th-darmstadt.de> <483pe6$aft@spool.cs.wisc.edu> <wkdrSOS00YUsM7OxBb@andrew.cmu.edu> <48bjig$rgj@inca01.inca.co.nz> <816741669snz@genesis.demon.co.uk> <49tu81$jcf@otis.netspace.net.au> Date: Mon, 4 Dec 1995 13:39:26 GMT