From owner-freebsd-hackers  Wed Jan 17 22:27:55 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA19847
          for hackers-outgoing; Wed, 17 Jan 1996 22:27:55 -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 WAA19827
          for <hackers@freebsd.org>; Wed, 17 Jan 1996 22:27:45 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA30637; Thu, 18 Jan 1996 17:17:05 +1100
Date: Thu, 18 Jan 1996 17:17:05 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601180617.RAA30637@godzilla.zeta.org.au>
To: hackers@freebsd.org, jkh@time.cdrom.com
Subject: Re: Change to stdio.h to export `cookie?'
Sender: owner-hackers@freebsd.org
Precedence: bulk

>Those users of our stdio's funopen() call are already familiar with
>the cookie I'm talking about - it's a magic variable in the FILE
>struct which you can set to things for the benefit of your own I/O
>functions.  The only problem is that the API designers didn't provide
>a hook for getting/setting it, leading to code which makes assumptions
>about the inside of the FILE structure.  I don't know if anyone's ever

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

>Any objections to an accessor macro being added to stdio.h?  I don't

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

Bruce