From owner-freebsd-hackers  Thu Jan 18 14:15:27 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id OAA07997
          for hackers-outgoing; Thu, 18 Jan 1996 14:15:27 -0800 (PST)
Received: from bsdi.BSDI.COM (bsdi.BSDI.COM [205.230.224.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA07991
          for <hackers@freebsd.org>; Thu, 18 Jan 1996 14:15:23 -0800 (PST)
Received: (from torek@localhost) by bsdi.BSDI.COM (8.6.12/8.6.12) id PAA20081; Thu, 18 Jan 1996 15:15:11 -0700
Date: Thu, 18 Jan 1996 15:15:11 -0700
From: Chris Torek <torek@BSDI.COM>
Message-Id: <199601182215.PAA20081@bsdi.BSDI.COM>
To: jkh@time.cdrom.com
Subject: Re: Change to stdio.h to export `cookie?'
Cc: hackers@freebsd.org, markd@grizzly.com
Sender: owner-hackers@freebsd.org
Precedence: bulk

>I guess why I didn't really consider fileno() to begin with is that I
>didn't think it was guaranteed to be a macro - is that mandated by the
>spec?

No, but there is or was code in X11 of the form:

	fileno(fp) = 2;

That kind of forced the issue. :-)

>Well, I guess what I'm trying to say is that there are certainly
>circumstances where it *can* be associated with a valid descriptor,
>and might it not be reasonable to make provisions for setting it?

On a UNIX box, maybe (but there you can simply use the fileno() hack).
On another machine, a FILE might really be a wrapper around something
like an RMS FCB.

>I'm open to [fpending] suggestions.. :-)

I would probably write it as a function (leave macro conversion for
`proven demand' :-) ).  For my stdio it would end up being something like:

	/* return count of input waiting to be read or output
	   waiting to be flushed */
	if (fp->_flags & __SRD)
		return (fp->_r);
	if (fp->_flags & __SWR)
		return (fp->_p - fp->_bf._base);
	/* must be in "indeterminate" read/write mode */
	return (0);

Perhaps it should also take an option to tell how much room is left
in a write buffer before the underlying file object's write function
is invoked.

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

Hmm.  One problem here is that the cookie in a regular old fopen()ed
file *is* used; it points back to the FILE struct.  A user-definable
field should probably be separate.  If you fiddle with stdout->_cookie,
you will get burned....

Chris