🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.powerpc
Article #19

Re: 64-bit

#19
From: Dan Pop
Date: Mon, 04 Dec 1995 13:39
51 lines
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!danpop
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>

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