From owner-freebsd-hackers Thu Jan 18 02:01:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA18993 for hackers-outgoing; Thu, 18 Jan 1996 02:01:37 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA18984 for ; Thu, 18 Jan 1996 02:01:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA23709; Thu, 18 Jan 1996 02:00:52 -0800 To: Chris Torek cc: markd@grizzly.com, hackers@freebsd.org Subject: Re: Change to stdio.h to export `cookie?' In-reply-to: Your message of "Thu, 18 Jan 1996 02:33:03 MST." <199601180933.CAA22395@bsdi.BSDI.COM> Date: Thu, 18 Jan 1996 02:00:52 -0800 Message-ID: <23707.821959252@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk >>If fd is -1, as it is when uninitialized ... > >It is not uninitialized, it is deliberately set to -1 to mean >`not associated with a file descriptor'. There is no reasonable 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? > >#define fpending(fp) ((fp)->_p - (fp)->_bf._base) > > Probably not a bad idea, though this is only correct for write-mode. > A more general version might be proposed and sent to ANSI for C9X... I'm open to suggestions.. :-) > >#define fcookie(fp) ((fp)->_cookie) > > This (a) assumes that there is some magic value associated with a > `FILE *' and (b) that it has meaning to someone outside the read/write/ > seek/close functions. I find this suspicious. Were stdio a C++ thing, > fp->_cookie would be a private member.... Well, OK, so you caught me.. I am trying to layer some additional behavior on top of stdio and the read/write/seek/close redirection takes me *most* of the way there, but for the rest I needed to juggle some routines which accepted normal FILE* arguments into looking at the cookie and dispatching different routines for it. I have an existing framework that already passes FILE* pointers everywhere to work with, and I don't think that my situation is that uncommon. 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. Would you not say that the FILE struct has become pretty ubiquitious in UNIX? :-) > >#define ffd(fp) ((fp)->_file) > > Same as existing fileno(fp). Duh! I can't believe I said this. I blame the late hour, the coffee, the fact that my mother was deprived of oxygen for 4 months while carrying me! No, no wait.. :-) I should have checked stdio.h first. 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? If it were implemented as a function on some architecture then you'd have a hard time using it on the LHS of an expression, as I am. Jordan