Re: Announce: OpenToken 2.0 released

[Hyman Rosen <hymie@prolifics.com>]

Robert A Duff <bobduff@world.std.com> 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.