Getting the file name from a FILE *

[Richard Tobin]

I meant the people *using* fopen. What if malloc fails? Should fopen return
NULL suddenly while the file couldve been opened?

That can happen anyway, if it can't allocate the FILE struct or the
buffer. A few extra bytes for an open file is neither here nor there
on typical systems.

If you were talking about an embedded system it might be an issue, but
so would be the whole of stdio.

-- Richard

 

[jacob navia]

That can happen anyway, if it can't allocate the FILE struct or the
buffer. A few extra bytes for an open file is neither here nor there
on typical systems.

If you were talking about an embedded system it might be an issue, but
so would be the whole of stdio.

-- Richard

If the allocation for the file name fails a NULL pointer will be stored
in the file structure and the file name will not be available.

Nothing horrible.

 

[jacob navia]

Yes but it can fail. Will fopen return NULL on failure of strdup or
return a valid FILE pointer. When the buffer fails to be allocated in
fopen this is a critical error and fopen should return NULL but not
being able to allocate the filename is not crititical and if you return
NULL one cant distingish between allocation failure and "non named
files" anymore.

So what?

I really think you should keep this out the library and
let clients deal with this who have more context in their own programs
anyway.

Obviously if the users allocate the buffer for the
file name that can never fail

 

[Richard Tobin]

If the allocation for the file name fails a NULL pointer will be stored
in the file structure and the file name will not be available.

That seems quite reasonable, given that programs have to be able to
deal with the file name being unavailable anyway.

Of course, if malloc() fails in fopen(), the chances are the rest of
the program won't work.

-- Richard

 

[jacob navia]

jacob navia said:


So the programmer can't rely on _fname or whatever you decide to call it,

He can't even rely that if fopen returns NULL it is because
the file name has a problem... It could be that there is no
more memory to allocate the FILE structure. So, following
your logic he should try to open the file himself and
go directly through the OS routines.

Why bother with fopen?

If it returns NULL you have no idea what happened. It could be the
file that is not available, the disk that is dead, the
moon that is absent, whatever.

so he'll end up keeping track of the filename himself (which in any case
is what he currently has to do, so it's no big deal to him), and your
function will remain unused except by the clueless.

Obvious. Just do not use lcc-win, do not pollute the threads I start.

Just GO AWAY!

[snip]

You should avoid sarcasm, because you're no good at it.

Did I ask for any advice? Keep it for yourself.

 

[Serve Lau]

He can't even rely that if fopen returns NULL it is because
the file name has a problem... It could be that there is no
more memory to allocate the FILE structure. So, following
your logic he should try to open the file himself and
go directly through the OS routines.

No because usually FOPEN_MAX FILE structs are preallocated together with
stdin stdout and stderr so there is a way to check for that error when
calling fopen and if allocating the internal buffer fails this would be
related to the actual file mechanism and it makes sense for fopen to return
NULL.
And how are you going to handle wide chars? It seems there's no such
function as wfopen in the C standard but I know windows comes with one. That
one will keep track of the filename in wide chars with _wfname or something?
Or will you just skip that one?

Another thing why it should not be in there imo is that people who already
implemented their own mechanism for keeping track of filenames will now have
2 mechanisms without even knowing it.

 

[forkazoo]

Hi
We are rewriting the libc for the 64 bit version of lcc-win
and we have added a new field in the FILE structure:
        char *FileName;
fopen() will save the file name and an accessor function
will return the file name given a FILE *.

Questions:

What would be the best name for this function?
        char *fname(FILE *); // lower case, short, similar to other
                              // file functions

        // clear name but maybe too long?
        char *FileNameFromFileP(FILE *);

Personally, I'd like something like lcc_fname(). It's still nice and
short, and lower case, and easy to type, but if a user ever moves a
codebase to another tool, a simple prefix naming convention would make
it easiest to spot the places that need change. And, if ISO ever gets
inspired by your work and adds a standard fname function which behaves
somewhat differently, you won't have to worry about naming overlap.

 

[Keith Thompson]

jacob navia skrev:

jacob navia wrote: [...]
Questions:

What would be the best name for this function?

_fname

Yes, it is better with the underscore

It avoid polluting the name space.

I have often used 'fname' as an identifier in my own projects, and
wouldn't take it lightly if the compiler I was using, didn't accept
strictly conforming code because of such a thing.

[...]

It's not an issue for strictly conforming code if jacob takes my
advice and declares the function in an implementation-defined header
rather than in stdio.h.

But I just realized that, as far as I know, jacob's nntp host,
aioe.org, still isn't showing articles posted from rr.com. Due to
some system problems on my end, I can't conveniently post through
aioe.org as I've done in the past. (This will be resolved, in a
sense, when Time Warner Cable, owner of rr.com, drops Usenet support.
Grrr.)

Can someone please post a followup quoting this in full so jacob can
see it?

 

[Keith Thompson]

The following is off-topic, but possibly of interest to some readers
of comp.lang.c. I've removed comp.compilers.lcc.

Keith Thompson skrev: [...]

But I just realized that, as far as I know, jacob's nntp host,
aioe.org, still isn't showing articles posted from rr.com. Due to
some system problems on my end, I can't conveniently post through
aioe.org as I've done in the past. (This will be resolved, in a
sense, when Time Warner Cable, owner of rr.com, drops Usenet support.
Grrr.)

Didn't Road Runner receive UDP for a period, because they didn't take
actions against spammers?

Yes, but the UDP appears to have been lifted, at least to the extent
that my articles posted through rr.com started showing up *except* at
aioe.org. I asked the aioe.org folks to unblock rr.com; they said
they had done so, but my articles still didn't show up. (I haven't
checked in the last few days.) Since aioe.org is a volunteer effort,
I'm not going to complain too loudly.

Time to move on... to a different ISP.

Roadrunner still appears to be the best option for a high-speed
connection in my area. At least there are other options for nntp
access.

 

[John Bode]

Hi
We are rewriting the libc for the 64 bit version of lcc-win
and we have added a new field in the FILE structure:
char *FileName;
fopen() will save the file name and an accessor function
will return the file name given a FILE *.

Questions:

What would be the best name for this function?
char *fname(FILE *); // lower case, short, similar to other
// file functions

// clear name but maybe too long?
char *FileNameFromFileP(FILE *);

Of the choices presented, fname(); it fits with the rest of the C API.

What problems could arise with this function? Why is not in the C API?

Given that you need to pass a path name to fopen() in order to open or
create a file in the first place, it was probably assumed that the
programmer would keep track of that information himself.

Also, the Unix file system (which was the environment C was originally
developed in) did not store the file name as part of the inode.

<snip remainder>

 

[Bartc]

No because usually FOPEN_MAX FILE structs are preallocated together with
stdin stdout and stderr so there is a way to check for that error when
calling fopen and if allocating the internal buffer fails this would be
related to the actual file mechanism and it makes sense for fopen to
return NULL.
And how are you going to handle wide chars? It seems there's no such
function as wfopen in the C standard but I know windows comes with one.
That one will keep track of the filename in wide chars with _wfname or
something? Or will you just skip that one?

Another thing why it should not be in there imo is that people who already
implemented their own mechanism for keeping track of filenames will now
have 2 mechanisms without even knowing it.

Or possibly 3 mechanisms, if they use Windows. The latter has a function
GetFinalPathNameByHandle() which is along the lines of what is proposed
(although it looks like it assembles the file name rather than stores it).

It might even possible for Jacob to make use of this function; although the
specs will be a little different, all the complications mentioned here will
disappear, or at least become the responsibility of MS.

 

[Richard Bos]

Nope. While the file was open, another process deleted the same
file and opened a new file under the same name. Now any fopens
will access the new file. However, the old file is still open,
usable, and nameless. Under Linux/Unix/Posix.

You forget that we're talking about a specific implementation[1]. Unix
does not exist, because it's Not Windows, and therefore Not Possible.

Richard

[1] And therefore this thread is off-topic in one of the groups posted
to; follow-up set.

 

[Nick Keighley]

"jacob navia" <[email protected]> schreef in berichtnews:[email protected]...

No because usually FOPEN_MAX FILE structs are preallocated together with
stdin stdout and stderr

is this documented in the standard? There's mention in this
thread of OSs that support 10,000 (or more) open files. Do they
create 10,000 file structures on startup? Sounds a bit wasteful...

so there is a way to check for that error when
calling fopen and if allocating the internal buffer fails this would be
related to the actual file mechanism and it makes sense for fopen to return
NULL.

<snip>

 

[Richard Tobin]

No because usually FOPEN_MAX FILE structs are preallocated together with
stdin stdout and stderr

[/QUOTE]

It includes those three.

is this documented in the standard? There's mention in this
thread of OSs that support 10,000 (or more) open files. Do they
create 10,000 file structures on startup? Sounds a bit wasteful...

FOPEN_MAX is the number of files that you are guaranteed to be able to
have open simultaneously. Long ago, some systems only had a fixed
array of FILE structs, and it was the size of that array. Most modern
systems have that many preallocated, and allocate more as required.

Of course, it's not that much of a guarantee, because it can't
take account of things like per-user limits on the number of open
files.

-- Richard

 

[Richard]

jacob navia said:


I try hard to follow my advice. I suggest you do the same.

You really are quite a nasty piece of work Heathfield. Rather than
badger Jacob, could I suggest you go and prance around elsewhere rather
than polluting otherwise civil threads with your egotistical ravings?

 

[Richard]

Nobody seems to have noticed this objection to the idea. Repost.



Many large problems on Linux/Unix. A file may be accessed via a
name, but once open it is nameless, and may well be identical to a
file opened with another program under another name, including
using identical storage. This is simply not a possible function.
If you want to know what name you used to open it, all you have to
do is remember it.

Just because things work on primitive operating systems, such as
Winders, doesn't mean they can work everywhere.

What OS is "Winders"?

 

[jacob navia]

What OS is "Winders"?

Must be HIS OS of course. It is surely a good fit for him

 

[John Bode]

Must be HIS OS of course. It is surely a good fit for him

So, no response to the substance of Chuck's criticisms?

How would you deal with hard links? Soft links (aliases)? Streams
opened by functions other than fopen() or freopen()? Are you
returning simply the file name, or the full path name (if you're
talking about error messages, the full path name would be useful)? If
there is no name associated with the file, would you return an empty
string or NULL? How would you distinguish between streams that had no
name to begin with vs. streams where the name could not be stored due
to an error?

What's the behavior if you call _fname() on a stream that has been
closed?

 

[jacob navia]

So, no response to the substance of Chuck's criticisms?

How would you deal with hard links?

I repeat: fname returns the first argument of fopen.

Soft links (aliases)?

Ditto

Streams
opened by functions other than fopen() or freopen()?

fname receives a FILE *. not a file descriptor

Are you
returning simply the file name, or the full path name (if you're
talking about error messages, the full path name would be useful)?

only the file name

If
there is no name associated with the file, would you return an empty
string or NULL?
NULL

How would you distinguish between streams that had no
name to begin with vs. streams where the name could not be stored due
to an error?

For stdin stdout and stderr "..stdin.." "..stdout.." and "..stderr.."
is returned.

What's the behavior if you call _fname() on a stream that has been
closed?

Returns NULL

 

[Ben Bacarisse]

So, no response to the substance of Chuck's criticisms?

How would you deal with hard links? Soft links (aliases)? Streams
opened by functions other than fopen() or freopen()? Are you
returning simply the file name, or the full path name (if you're
talking about error messages, the full path name would be useful)? If
there is no name associated with the file, would you return an empty
string or NULL? How would you distinguish between streams that had no
name to begin with vs. streams where the name could not be stored due
to an error?

This is one of the odd argument where I find myself on both sides. I
think these problems miss the point -- it always up the programmer to
know if a file name makes any sense, and it seems all Jacob is
suggesting is that he store what use at the point of the open call and
offer to return it later[1]. (Personally I would not copy it. I'd
store the pointer used in the fopen/freopen and hand that back when
asked.) This would be mildly useful -- I have done this short of
thing 100 times and if the stored pointer idea had been part of K&R's
FILE * interface or ANSI's I'd have used it gladly.

But it was not. The only value in implementing it is as an example
when making a case for a change to the standard. I doubt that the
benefit is enough to merit such a change, and one would have to advice
anyone thinking of using such a mechanism to avoid it, since it's only
purpose will be to make their programs slightly less portable.

[1] If he is proposing something stronger (like trying to find some
canonical representation of the opened file's name and storing that)
then I agree that these criticisms are valid, but I thought (at least
at first) he was simply suggesting that the pointer be stored.