From owner-freebsd-hackers  Thu Jan 18 14:17:27 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id OAA08131
          for hackers-outgoing; Thu, 18 Jan 1996 14:17:27 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA08121
          for <hackers@FreeBSD.ORG>; Thu, 18 Jan 1996 14:17:18 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA06336; Thu, 18 Jan 1996 15:10:03 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199601182210.PAA06336@phaeton.artisoft.com>
Subject: Re: Change to stdio.h to export `cookie?'
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Thu, 18 Jan 1996 15:10:03 -0700 (MST)
Cc: torek@BSDI.COM, markd@grizzly.com, hackers@FreeBSD.ORG
In-Reply-To: <23707.821959252@time.cdrom.com> from "Jordan K. Hubbard" at Jan 18, 96 02:00:52 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> > >#define fcookie(fp)     ((fp)->_cookie)
> > 
> > This (a) assumes that there is some magic value associated with a
> > `FILE *' and (b) that it has meaning to someone outside the read/write/
> > seek/close functions.  I find this suspicious.  Were stdio a C++ thing,
> > fp->_cookie would be a private member....
> 
> Well, OK, so you caught me..  I am trying to layer some additional
> behavior on top of stdio and the read/write/seek/close redirection
> takes me *most* of the way there, but for the rest I needed to juggle
> some routines which accepted normal FILE* arguments into looking at
> the cookie and dispatching different routines for it.  I have an
> existing framework that already passes FILE* pointers everywhere to
> work with, and I don't think that my situation is that uncommon.
> 
> Most systems, like X, give you a little user-definable data area to
> play with if you're going to be passing highly ubiquitous types (like
> window IDs) around because it's just too darn useful of a function not
> to provide.  Would you not say that the FILE struct has become pretty
> ubiquitious in UNIX? :-)

Try "caddr_t userdata" or soemthing that implies you can mung it, then.

Personally, I'd use:

	struct myfile {
		FILE	*fp;
		caddr_t	*userdata;
	}

And wrapper all FILE * manipulation functions instead.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.