Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: magic cookies given back by ftell, and used in fseek
Message-ID: <11695@mimsy.UUCP>
Date: 27 May 88 19:22:58 GMT
References: <129@lakart.UUCP> <1024@cresswell.quintus.UUCP> <4253@haddock.ISC.COM> <1029@cresswell.quintus.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

In article <1029@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe)
writes:
>What we have here is an abstract data type "stream position"
>whose representation happens to be an integer. ...

... which is somewhat unfortunate; the `format of choice' in C for
ADTs is an opaque pointer (`void *').

>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.

Yes.  `&c' is `seek'; these are the only operations used in stdio itself.

>One thing I would like in that is programmer-defined stream position objects.

Unfortuantely, if the new interface is to be compatible with the old
---and this appears to be necessary to get the functions adopted anywhere;
certainly I would not install them here if they changed the return value
of fseek!---the return type must remain an integer (`long').

>I can't do [something useful] with only 32 bits to play with.  (Well,
>I can malloc() little blocks and return pointers to them, but there
>are problems with that.)

There *is* a solution, although it is not the prettiest:  Allocate a
block (`array') of real information, and return indicies into this
block (a la file descriptors).  The block can be expanded as necessary
by using realloc().  The Unix kernel simplifies the task by fixing
the number of descriptors (usually at something like 20 or 64 or 256).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris