> From [EMAIL PROTECTED] Fri Mar 21 16:04:58 2003
> On Thu, Mar 20, 2003 at 09:07:39PM -0800, Joey Hess wrote:
> > Walter Tautz wrote:
> > > please retain the CC to rbutterworth
> > >
> > >
> > > Subject: Linux stdio question.
> > >
> > > On non-linux unix systems, one can reference __iob[]
> > > to find all currently fopen()ed files
> > > (e.g. when forking a new process one would generally
> > > want to flush their buffers first, or perhaps close most of them).
> > >
> > > Linux's stdio.h doesn't provide such an array of open FILE pointers,
> > > or at least if it does I can't find it.
> > >
> > > Any idea what they call it,
> > > or how one can find all currently open FILEs?
> > >
> > > Perhaps there is a better way?
> > >
> > > A general guide to porting underlinux /debian would be appreciated.
> >
> > I've never run into __iob, but it looks quite nonportable. A similarly
> > nonportable way in linux is to examine /proc/self/fd/.
> >
> > I wonder if whatever unixes implement __iob have special kernel support
> > for it, or does libc just fill it in? I can't see how it could always
> > get at the info without kernel support. Just a point of personal interest..
>
> Well, __iob is reasonably portable because it looks like it's a standard
> part of a System V libc. In theory, I think glibc is supposed to support
> the System V ABI, but it doesn't seem to have an __iob[]. I don't think
> __iob is specified in any other standard, and different versions of the
> System V ABI standard don't even define it in quite the same way.
Note that I wasn't claiming it was portable,
just that a similar mechanism (e.g. "iob[]", "_iob[]", or "__iob[]")
exists in all the UNIX versions I've seen over the last 20+ years
except for in LINUX. And it's not only the SysV versions: BSD 4.3
had this in 1982:
extern struct _iobuf {
char *_ptr;
char *_rms;
char *_base;
long int _sectr;
short int _flag;
short int _cnt;
char _links;
char _file;
short int _maxoffset;
long int _maxsectr;
} _iob[_NFILE];
and I'm sure that earlier versions had something similar.
> Even if it did have an __iob[] you probably shouldn't be relying on
> somebody else to keep track of the files you have open. You're the only
> one who knows (or at least you're supposed to know) why you have files
> open, so you should usually be trying to make an informed decision about
> what to do with them.
>
> Thinking ahead about things like that is a good habit, I've had no end
> of headaches from listening to programmers going on about how the
> compiler/runtime/server/whatever "should do that for me" when you tell
> them their code is crashing because they didn't think about the side
> effects of what they were doing.
Yes, I agree totally. The problem is that I'm not writing the
programs themselves, but some general-purpose library functions
for others to use. For instance, if one of these library functions
needs to do something like fork a new process, it should do some
cleanup first, in which case it will need to know which "FILE *"
descriptors are still open. Until now, that has been a trivial task.
I can work around this, but was hoping someone had a quick
and simple answer (e.g. it's called "___iob[]").
Thanks for the suggestions and comments anyway.
But wait, the fflush((FILE *)0) call needs this same information too,
so what I wanted can't be that unreasonable or difficult.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
