Date: Thu, 18 Jan 1996 15:10:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: torek@BSDI.COM, markd@grizzly.com, hackers@FreeBSD.ORG Subject: Re: Change to stdio.h to export `cookie?' Message-ID: <199601182210.PAA06336@phaeton.artisoft.com> In-Reply-To: <23707.821959252@time.cdrom.com> from "Jordan K. Hubbard" at Jan 18, 96 02:00:52 am
index | next in thread | previous in thread | raw e-mail
> > >#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.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601182210.PAA06336>