Getting the file name from a FILE *

[jacob navia]

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 *FileNameFromFi leP(FILE *);

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

We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.

Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but

struct __FILE;
typedef struct __FILE FILE;


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[vippstar@gmail.com]

Re: Getting the file name from a FILE *

On Jun 20, 6:11 pm, jacob navia <ja...@nospam.c omwrote:

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 *.

What should it return for tempfile(), stdin, stdout, stderr?

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 *FileNameFromFi leP(FILE *);
>
What problems could arise with this function? Why is not in the C API?

Because FILE needs not to be a struct.
Also, why not just write it as a macro in all caps? All you do is
return an element from the struct anyway...

We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.
>
Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but
>
struct __FILE;
typedef struct __FILE FILE;

I don't understand these last two lines...

[Joachim Schmitz]

Re: Getting the file name from a FILE *

jacob navia wrote:

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 *FileNameFromFi leP(FILE *);
>
What problems could arise with this function? Why is not in the C API?

What happens if the file gets deleted (remove()/unlink()), while it is still
open (in POSIX that is possible, not sure what the C Standard nor Windowds
says about this)?
In that case the filename would have disappeared, no longer exist.

We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.
>
Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but
>
struct __FILE;
typedef struct __FILE FILE;

[Walter Roberson]

Re: Getting the file name from a FILE *

In article <g3ghbs$j5j$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>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 *.

What is the "file name" of a socket or pipe? Of a file created
by tmpnam() ? Of stdin? If all the calling program hands you is
the open file, then -which- of the several possible names for it
are you going to find for the file, in a system which has true symbolic
links? In a system which has Alternate Data Streams (ADS) that
can be programs that have effects similar to symbolic links or
to loop-back mounts?
--
"The Romans believed that every man had his Genius, and every
woman her Juno." -- Thomas Bulfinch

[jacob navia]

Re: Getting the file name from a FILE *

vippstar@gmail. com wrote:

On Jun 20, 6:11 pm, jacob navia <ja...@nospam.c omwrote:

>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 *.

What should it return for tempfile(), stdin, stdout, stderr?

For tempfile() should return... the name of the temporary file of course
For stdin it will return an invalid file name (either NULL or
"....stdin. ..." or similar.
For stdout/stderr the same.

>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 *FileNameFromFi leP(FILE *);
>>
>What problems could arise with this function? Why is not in the C API?

Because FILE needs not to be a struct.

Yes, but why can't the C library return a file name from
the FILE *?

This has noting to do with the actual layout of the FILE

Also, why not just write it as a macro in all caps? All you do is
return an element from the struct anyway...
>

>We are considering extending our file functions to handle
>file attributes that many file systems support. We will have two
>pointers that point to extended attributes and a "user" pointer,
>i.e. a pointer that would be set by the user and would carry user
>defined data that we would not touch. An accessor/setter function
>would allow the user to set/retrieve data.
>>
>Note that the FILE structure is now a completely opaque structure.
>No definition for FILE will be available to the user but
>>
>struct __FILE;
>typedef struct __FILE FILE;

I don't understand these last two lines...

Well this is standard C. The first line defines an opaque structure
called __FILE.
The second defines a pointer to that opaque structure.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Johannes Bauer]

Re: Getting the file name from a FILE *

jacob navia schrieb:

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

Shouldn't you return a const char*?

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

What are you doing with open -fdopen FILE*s? All you have is the file
descriptor here, no way to get a file name.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47fa8447$0$115 45$9b622d9e@new s.freenet.de>

[jacob navia]

Re: Getting the file name from a FILE *

Joachim Schmitz wrote:

jacob navia wrote:

>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 *FileNameFromFi leP(FILE *);
>>
>What problems could arise with this function? Why is not in the C API?

What happens if the file gets deleted (remove()/unlink()), while it is still
open (in POSIX that is possible, not sure what the C Standard nor Windowds
says about this)?

If the file is still open and you can delete the file, the name of
the file doesn't change of course. It is still whatever it was.
And if you can still fwrite to an inexistent file, then
what happens with the name is not as important as what
happens with the data you write into... yes into what?

In that case the filename would have disappeared, no longer exist.
>

The file name will be returned by fopen if the file
is not closed. If that file exists, or not, that is not
our problem. If you did a

format c:

and the whole drive doesn't exist, this is NOT our problem.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Re: Getting the file name from a FILE *

Johannes Bauer wrote:

jacob navia schrieb:
>

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

>
Shouldn't you return a const char*?
>

Yes!

Thanks for that tip.

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

>
What are you doing with open -fdopen FILE*s? All you have is the file
descriptor here, no way to get a file name.
>

Luckily we do not support the low level primitives (open/close/fdopen,
etc). Maybe in a future release...


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[vippstar@gmail.com]

Re: Getting the file name from a FILE *

On Jun 20, 7:00 pm, jacob navia <ja...@nospam.c omwrote:

vipps...@gmail. com wrote:

On Jun 20, 6:11 pm, jacob navia <ja...@nospam.c omwrote:

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 *.

What should it return for tempfile(), stdin, stdout, stderr?

>
For tempfile() should return... the name of the temporary file of course
For stdin it will return an invalid file name (either NULL or
"....stdin. ..." or similar.
For stdout/stderr the same.
>

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 *FileNameFromFi leP(FILE *);

>

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

Because FILE needs not to be a struct.

>
Yes, but why can't the C library return a file name from
the FILE *?
>
This has noting to do with the actual layout of the FILE

It's actually useless. If the programmer cares, he can write his own
struct (and functions that modify it), for example
struct myfile { FILE *fp; const char *filename; }
I remember another thread where someone asked why there isn't an
isodigit (similar to isxdigit, for octal numbers)
Presumably for the same reason: they either haven't though of it, or
because it's easy to implement.
Same say for memmem() (like strstr()).

>

Also, why not just write it as a macro in all caps? All you do is
return an element from the struct anyway...

>

We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.

>

Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but

>

struct __FILE;
typedef struct __FILE FILE;

I don't understand these last two lines...

>
Well this is standard C. The first line defines an opaque structure
called __FILE.
The second defines a pointer to that opaque structure.

Ah yeah, sorry for that, it confused me so much, but now it seems
quite clear that what it does is ok. (It defines an alias, not a
pointer though)
Why do that instead of simply struct FILE?
Mr Joahim Schmitz made a valid point: what do you do when remove() is
called?

Also, *WHY* do you want to add that? It doesn't seem particularly
useful to me.

[vippstar@gmail.com]

Re: Getting the file name from a FILE *

On Jun 20, 7:08 pm, jacob navia <ja...@nospam.c omwrote:

Johannes Bauer wrote:

jacob navia schrieb:

>

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

>

Shouldn't you return a const char*?

>
Yes!
>
Thanks for that tip.
>

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

>

What are you doing with open -fdopen FILE*s? All you have is the file
descriptor here, no way to get a file name.

>
Luckily we do not support the low level primitives (open/close/fdopen,
etc). Maybe in a future release...

I don't see how what Mr Schmitz says is a problem.
You don't have to implement these, they are POSIX, and windows has
them as well. It's known that mixing read/write/etc calls with FILE*
can result in weird behavior, and that is not because of the way *you*
implemented FILE * and related functions

[Eric Sosman]

Re: Getting the file name from a FILE *

jacob navia wrote:

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 *FileNameFromFi leP(FILE *);

I'd vote for fname().

What problems could arise with this function?

A few problems I can think of off-hand:

- Some streams might not be associated with named files.
The problem isn't insuperable -- you could return NULL
or "" or some such -- but it's a problem.

- Interaction with rename() and remove() could be tricky,
especially when a file has more than one name (e.g.,
"foo", "./foo", "/user/jnavia/projects/foo", ...).
Since the effect of rename() or remove() on a file with
open streams is implementation-defined, you're free to
define your way out of the problem by ignoring it, but
then one starts to ask whether the result of fname() is
useful. For decoration in messages, maybe, but ...

- Similar issues arise on systems that provide a "change
directory" operation, if the name is "relative" and the
directory changes between fopen() and fname().

- The returned type should probably be `const char*'.
Whether the argument should be const-qualified is a
trickier matter, since it would place constraints on
the implementation (e.g., no "lazy fill-in").

Why is not in the C API?

Sounds like a comp.std.c question. Speculation: The
committee was chartered to codify existing practice, and there
was insufficient existing practice for such a function.

--
Eric.Sosman@sun .com

[Eric Sosman]

Re: Getting the file name from a FILE *

jacob navia wrote:

Joachim Schmitz wrote:

>jacob navia wrote:

>>[...]
>>fopen() will save the file name and an accessor function
>>will return the file name given a FILE *.
>>[...]
>>What problems could arise with this function? Why is not in the C API?

>What happens if the file gets deleted (remove()/unlink()), while it is
>still open (in POSIX that is possible, not sure what the C Standard
>nor Windowds says about this)?

>
If the file is still open and you can delete the file, the name of
the file doesn't change of course. It is still whatever it was.

This is not the case on Unix-derived systems. If the
file is deleted while open, it has *no* name[*]. Furthermore,
the former name can be used to create a new file that need
not have anything to do with the nameless file.
[*] Well, it doesn't have *that* name. Because of what
Unix file systems call "hard links," a file can have many
aliases.

--
Eric.Sosman@sun .com

[Daniel Pitts]

Re: Getting the file name from a FILE *

jacob navia wrote:

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 *FileNameFromFi leP(FILE *);
>
What problems could arise with this function? Why is not in the C API?
>
We are considering extending our file functions to handle
file attributes that many file systems support. We will have two
pointers that point to extended attributes and a "user" pointer,
i.e. a pointer that would be set by the user and would carry user
defined data that we would not touch. An accessor/setter function
would allow the user to set/retrieve data.
>
Note that the FILE structure is now a completely opaque structure.
No definition for FILE will be available to the user but
>
struct __FILE;
typedef struct __FILE FILE;
>
>

Why are you saving the filename? That seems like a bad idea, unless it
is necessary to implement the system code. Keep the FILE * to its core
purpose. Follow the KISS principal.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity .net/wordpress/>

[Keith Thompson]

Re: Getting the file name from a FILE *

jacob navia <jacob@nospam.c omwrites:

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 *FileNameFromFi leP(FILE *);

I mildly prefer "fname". I strongly suggest that it *not* be declared
in <stdio.h>, even in non-conforming mode.

What problems could arise with this function?

It assumes that each stream is associated with exactly one file name.
Depending on the system, some streams are not associated with any
named file, and some many have multiple equally valid names.

There are a number of decisions you'd have to make *and document*
about the form of the name. For Windows, you've already specified
lower case, which isn't necessarily ideal. Other possibilities are
the name used to open it, and the name as stored in the directory
(NTFS remembers case distinctions in file names, but doesn't enforce
them).

Does the Windows API already provide something like this? I have no
idea whether it does or not; if it does, the existing interface might
provide some guidance, or even make your function unnecessary.

You should think about when and whether the name is going to be
useful. If you grab the name of a file and then close it, can you
re-open it with the same name?

Why is not in the C API?

I don't know. Probably lack of existing practice and limited utility.
It's usually easy enough to remember the name when you open the file.

[snip]

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[mingyanguo]

Re: Getting the file name from a FILE *

On Jun 20, 9:41 am, Eric Sosman <Eric.Sos...@su n.comwrote:

jacob navia wrote:

Joachim Schmitz wrote:

jacob navia wrote:
>[...]
>fopen() will save the file name and an accessor function
>will return the file name given a FILE *.
>[...]
>What problems could arise with this function? Why is not in the C API?
What happens if the file gets deleted (remove()/unlink()), while it is
still open (in POSIX that is possible, not sure what the C Standard
nor Windowds says about this)?

>

If the file is still open and you can delete the file, the name of
the file doesn't change of course. It is still whatever it was.

>
This is not the case on Unix-derived systems. If the
file is deleted while open, it has *no* name[*]. Furthermore,
the former name can be used to create a new file that need
not have anything to do with the nameless file.

This is the point. A process opens file 'A', gets a FILE for it and
remembers its name 'A'. Then another process unlinks file 'A' and
reuses the name 'A' to create another file. Now if the previous
process tries to refer a file via the file name 'A', it will get the
new file, and worse, it is difficult for the process to know if the
file named 'A' is the one it opened or a new file created by others.
So, remembering the file name for a FILE rarely makes sense.

>[*] Well, it doesn't have *that* name. Because of what
Unix file systems call "hard links," a file can have many
aliases.
>
--
Eric.Sos...@sun .com

Regards,
MingyanGuo