Date: Thu, 18 Jan 1996 15:15:11 -0700 From: Chris Torek <torek@BSDI.COM> To: jkh@time.cdrom.com Cc: hackers@freebsd.org, markd@grizzly.com Subject: Re: Change to stdio.h to export `cookie?' Message-ID: <199601182215.PAA20081@bsdi.BSDI.COM>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601182215.PAA20081>