Re: [ot] Linux stdio question, howto find fopened files

["Ray Butterworth" <rbutterworth@math.uwaterloo.ca>]

>  From mkh01@earthlink.net  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.