Re: Getting the file name from a FILE *
- From: roberson@xxxxxxxxxxxxxxxxxx (Walter Roberson)
- Date: Thu, 26 Jun 2008 16:17:34 +0000 (UTC)
In article <g3vfoj086c@xxxxxxxxxxxxxxxxx>,
Chris Torek <nospam@xxxxxxxxx> wrote:
In article <Y3y8k.15793$E41.3023@xxxxxxxxxxxxxxxxxxxxxxxxx>
Bartc <bc@xxxxxxxxxx> wrote:
Use of fname() allows retrieval of a filename from any file opened with
fopen() from many millions of lines of existing code with /no changes/ to
those lines (which in some cases may not be accessible anyway).
The objections are:
There is an issue that I haven't observed being addressed in this
thread, which is that in general, what you want to present in error
messages (and the like) is not necessarily the file name that the file
was openned with, but rather some kind of user- meaningful identifying
string -- which might perhaps include the filename openned with, might
perhaps include the directory, might perhaps include a phrase such as
"configuration file", might perhaps include the phrase "temporary swap
file", might perhaps say "standard input" and so on.
If the idea is to have something to present for error/warning messages,
then an "identifying string" is more useful than just the file
name that might happened be passed to fopen -- e.g., the file name passed
might be relative to the current directory and so the name by itself
might not be very useful. [*]
Of course, passing in an identifying string for fopen to squirrel
away would require a change to the API to fopen(), which would
Not Be Cool considering the amount of code that presently uses fopen.
In theory, the API for fopen() could be extended by adding a varargs
parameter, but as there can be considerable differences in parameter
passing between non-varargs routines and varargs routines, taking
this approach would likely require a recompile / relink of lots of
existing code even though the code did not use the new facilities;
I expect that that recompile / relink step would not be considered
an acceptable cost for this functionality. There are work-arounds
to this issue, such as having fopen() record the filename
as the default identifying tag (as Jacob proposed), but also adding a
routine which could change the tag to something else after the
fopen().
([*] Note: in Unix and [I think] MS Windows with NTFS filesystems, there
can be files that you can open relatively but which you could not open
if you used the absolute path, because in Unix at least, you are given
authorization to access your home directory even if your user does not
have permission to traverse the directory tree to reach your home
directory. In Windows with NTFS Alternative Data Streams (ADS),
I believe that the effect of reading a file through one path could be
different than the effect of reading it through a different path,
since a component on the pathname could [if I understand
properly] have an ADS that could be (e.g.,) a decryptor or decompressor.)
--
"To all, to each! a fair good-night,
And pleasing dreams, and slumbers light" -- Sir Walter Scott
.
- References:
- Re: Getting the file name from a FILE *
- From: Chris Torek
- Re: Getting the file name from a FILE *
- Prev by Date: Re: types, variable names and fields
- Next by Date: Re: How to learn C ?
- Previous by thread: Re: Getting the file name from a FILE *
- Next by thread: share a variable across two libraries
- Index(es):
Relevant Pages
|
