Getting the pathname from a FILE*.

[John Chambers]

In article <560 at philmds.UUCP>, leo at philmds.UUCP (Leo de Wit) writes:
> In article <651 at umb.umb.edu> karl at umb.umb.edu (Karl Berry.) writes:
> >
> >The title says it all. Am I missing something obvious?
> >The pathname doesn't seem to be a field in either the
> >_iobuf or the structure returned by stat.
> >ttyname or ctermid will give you the pathname
> >of your terminal, but I want the pathname of an
> >arbitrary FILE* I have fopen. Or am I missing some
> >reason why this is not feasible?
> 
> What is the use? If you have opened the file, you used the filename 
> already (unless the open file is inherited from a parent process).

There are lots of uses.  Consider a problem I am having on a current
project:  A program running on a Sun is running out of files.  My code
opens maybe 6 or 8 files at the most.  So where do the others come from?
Easy - they are opened by library subroutines.  My code can't remember
the names of those files; my code didn't open them.  This makes debugging
very difficult.  Sun hasn't been very helpful, either.  Sure, I have a
routine to fstat() all the open files and print out the magic numbers.
That doesn't help me much in getting the answer to the question "What's
causing all those @#$*^% files to be opened?"

For debugging, it would be very useful if I could use a library that
would keep around a copy of the name used to open a file.  For inherited
files, the info *could* be passed in the environment.

The fact that some files have no valid name isn't a valid counter-argument.
For debugging purposes, it would be useful if some pseudo-names ("<stdin>",
"<socket>") were returned.  

Some of us occasionally write code that doesn't work the first time, and
we sometimes have a few problems figuring out what we did wrong.  Having
the libraries so secretive about what they're doing isn't very helpful.  

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]