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: 103376,6bf9d4ba0cfd8cb6 X-Google-Attributes: gid103376,public From: Hyman Rosen Subject: Re: Announce: OpenToken 2.0 released Date: 2000/02/17 Message-ID: #1/1 X-Deja-AN: 587061148 Sender: hymie@calumny.jyacc.com References: <3890C62B.18309585@telepath.com> <876unj$jcs$1@nnrp1.deja.com> <87d7qck6pm.fsf@deneb.cygnus.argh.org> X-Complaints-To: abuse@panix.com X-Trace: news.panix.com 950818877 18137 209.49.126.226 (17 Feb 2000 20:21:17 GMT) Organization: PANIX Public Access Internet and UNIX, NYC NNTP-Posting-Date: 17 Feb 2000 20:21:17 GMT Newsgroups: comp.lang.ada Date: 2000-02-17T20:21:17+00:00 List-Id: Robert A Duff writes: > If the *hardware* insists that the smallest integer type is 32 bits, > then is it unreasonable for the C implementation to read 32-bit > quantities? Surely, if char and int are the same size (say, 32 bits), I > should be allowed to write out the number -1, or 2**31-1, or 1_000_000! > And surely if I can write it out, I should be able to read it back in. But for now, and for the forseeable future, it's extremely unlikely that file contents will have a granularity no smaller than 32 bits. That means that stream input is still going to be reading octets, whether or not the processor likes to deal with quantities 32, or 64, bits at a time. I'm not saying that the situation you are describing could never, in principle, occur. I'm just saying that I don't think it will. If it does, than on that platform, you can not write your input code as 'int c; while ((c = getchar()) != EOF) { ... }', but C already has other mechanisms to deal with this case. But I don't think that it's necessary for the ordinary C programmer to worry about portability of everyday code to such an oddball platform.