Date: Thu, 18 Jan 1996 01:17:19 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mark Diekhans <markd@grizzly.com> Cc: hackers@freebsd.org, torek@bsdi.com Subject: Re: Change to stdio.h to export `cookie?' Message-ID: <23375.821956639@time.cdrom.com> In-Reply-To: Your message of "Wed, 17 Jan 1996 19:21:28 GMT." <199601171921.TAA17835@Grizzly.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> To prevent myself (and code I helped to put in Tcl/Tk) from being banned,
> how about a macro to determine if there is any data to be read pending in the
> buffer? Its essential if you want to do select on a buffered file.
I think this would be a good idea - figuring out the amount of data
buffered up is the same kind of FILE structure manipulation that MH
tries to do.
While we're at it, I think another macro to diddle the `_file' member
is probably also in order. Why? Because the *@#%$*%! funopen() call
returns a new FILE* with all the dispatch function pointers neatly
filled in, but it leaves the fd uninitialized. I found this out to my
despair when I created a fp with funopen(), passed it to TCL's
Tcl_EnterFile() function and watched that same function fall over with
a bus error. It falls over because of this code:
fd = fileno(file);
if (fd >= tclNumFiles) {
If fd is -1, as it is when uninitialized, the check will fail and try
to subsequently reference an array that's not set up yet. This means
that fileno(fp) should be valid for any fp created by funopen() lest
someone later do a fileno() on it, and that means going in and
tweaking it afterwards since fdopen() would just return yet another
file handle and that's not what we want, nor do I particularly feel
like adding another argument to funopen() (do I?).
OK, here's my proposed set of macros to go into stdio.h:
#define fcookie(fp) ((fp)->_cookie)
#define ffd(fp) ((fp)->_file)
#define fpending(fp) ((fp)->_p - (fp)->_bf._base)
If you call them on uninitialized file descriptors you lose, of
course, but I can live with that.
To recap for Chris, whom I've just added to the discussion, my
original beef came up with using funopen() and finding that there was
no standard way of manipulating the cookie. Since funopen() is
useless without this ability, and I hate code that manipulates the
FILE structure directly due to the portability problems it engenders,
this discussion ensued.
Thoughts?
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23375.821956639>