magic cookies given back by ftell, and used in fseek

[Richard A. O'Keefe]

In article <1024 at cresswell.quintus.UUCP> I wrote:
> The UNIX "ftell" manual page warns that on non-UNIX systems "arithmetic may
> not meaningfully be performed on" magic cookies, and you have to regard
> comparing for equality as arithmetic.
In article <4253 at haddock.ISC.COM>, karl at haddock.ISC.COM (Karl Heuer) wrote:
> That's not the common interpretation of "performing arithmetic".

What we have here is an abstract data type "stream position"
whose representation happens to be an integer.
Except in those implementations which explicitly define the representation
(as UNIX defines it to be a byte count) there is no reason to expect the
representation relation to have any particular properties (putting some
number of randomly generated bits in, provided that fseek() ignored them,
would be within the "abstract data type" idea).
We already know that memcmp() is not a good method of comparing
abstract data types represented as records, and for the same reason
'==' is not a good method of comparing abstract data types represented
as integers.  I think it is fair to say that ftell(stdin) == ftell(stdout)
is performing an arithmetic operation, because == is an arithmetic
comparison.

I think it was Chris Torek who said that he had a new version of stdio
which let the programmer specify his own read/write/close/&c.  One thing
I would like in that is programmer-defined stream position objects.
For example, suppose I want to implement "concatenated files" (which I
have wanted to do).  Then a stream position might be an index into a
table (or even a pointer) and a byte offset within the selected file.
I can't do that with only 32 bits to play with.  (Well, I can malloc()
little blocks and return pointers to them, but there are problems with that.)