Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: magic cookies given back by ftell, and used in fseek
Message-ID: <1024@cresswell.quintus.UUCP>
Date: 26 May 88 07:49:12 GMT
References: <129@lakart.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 26
Posted: Thu May 26 00:49:12 1988

In article <129@lakart.UUCP>, dg@lakart.UUCP (David Goodenough) writes:
> There has been much discussion in this group on the fact that on certain
> systems (VMS I believe), ftell & fseek use magic cookies to tell about
> file position. I have my asbestos suit ready if this suggestion is out of
> line, but have the ANSI comittee considered providing some means to convert
> from cookie format to and from character position in file. Come to that
> is such a thing possible?

Given the history of C, I suggest that the "magic cookie" idea may have had
more to do with the /370 or GECOS(sp?) implementations of C than with VMS.
Consider an IBM/370 "VB" file (variable length blocked records).  The
operating system wants you to position in the file by specifying the
relative block number (this is gross oversimplification, please don't
flame me, IBM fans).  If "character position" is interpreted as
(count of previous *blocks*) x (size of block) + (offset in current block)
then something could be done, but that won't be equal to the number of
characters getc() gave you while you were getting there.  For *real* fun
(fun until it hurts) try to figure out what magic cookies should do with
concatenated data sets.

Magic cookies should really be some sort of implementation-specific record.

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.  All you can do with a magic cookie
is say "go back there".