From owner-freebsd-hackers  Thu Jan 18 02:23:25 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA21613
          for hackers-outgoing; Thu, 18 Jan 1996 02:23:25 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA21575
          for <hackers@freebsd.org>; Thu, 18 Jan 1996 02:23:16 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA07686; Thu, 18 Jan 1996 21:07:18 +1100
Date: Thu, 18 Jan 1996 21:07:18 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601181007.VAA07686@godzilla.zeta.org.au>
To: bde@zeta.org.au, jkh@time.cdrom.com
Subject: Re: Change to stdio.h to export `cookie?'
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> Since the cookie points to an object that is decided by the caller
>> of funopen(), it is impossible to know what it points to.

>True, but when I have a fairly constrained set of circumstances where
>I know that the only FILE* pointers I'm being passed are ones created
>by funopen(), it's not a problem - I simply know what the cookie is
>going to be.

If you created them then you don't need any stdio support for them.
Do you just mean accessing your own cookies from outside the i/o
routines?  fp->_cookie is unportable but no worse than __getcookie(fp)
unless you're trying to establish a standard.  (fp->_read == my_read)
can be used to determine if you have fropen()ed the stream.  The
interface is certainly incomplete here.

>> It could only work for cookies created by the stdio implementation.
>> Ick.

>I'm not sure what you mean by this.

I thought you were talking about looking inside the cookie for cookies
not created by you.  This can only work for cookies created by the
stdio implementation.  You would need to keep track of where they are
created.

Bruce