Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #158297 > unrolled thread

Finding the name of a file

Back to article view | Back to comp.lang.c

Contents

  Finding the name of a file emanuele cannizzo <emacannizzo@gmail.com> - 2021-01-12 07:26 -0800
    Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 16:14 +0000
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-12 17:02 +0000
    Re: Finding the name of a file Christian Hanné <the.hanne@gmail.com> - 2021-01-12 17:29 +0100
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-12 17:03 +0000
      Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 19:52 +0000
    Re: Finding the name of a file Mark Bluemel <mark.bluemel@gmail.com> - 2021-01-12 08:37 -0800
    Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 19:41 +0300
      Re: Finding the name of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-12 09:34 -0800
        Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 20:56 +0300
    Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-12 09:42 -0700
      Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 16:56 +0000
        Re: Finding the name of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-12 19:58 +0300
        Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-12 11:25 -0700
        Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 20:12 +0000
          Re: Finding the name of a file Bart <bc@freeuk.com> - 2021-01-12 20:29 +0000
            Re: Finding the name of a file antispam@math.uni.wroc.pl - 2021-01-12 22:14 +0000
              Re: Finding the name of a file Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-12 15:12 -0800
                Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-15 07:41 +0000
                  Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-15 09:54 -0800
                    Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-15 21:02 +0000
                      Re: Finding the name of a file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-01-15 18:30 -0700
                        Re: Finding the name of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-01-16 07:47 +0000
                          Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 09:11 -0800
                            Re: Finding the name of a file Siri Cruise <chine.bleu@yahoo.com> - 2021-01-20 09:39 -0800
                              Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 08:52 -0800
                                Re: Finding the name of a file Vir Campestris <vir.campestris@invalid.invalid> - 2021-01-25 21:43 +0000
                                  Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-25 23:47 +0000
                                  Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:55 -0800
                      Re: Finding the name of a file Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 09:06 -0800
    Re: Finding the name of a file Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-12 18:18 +0000
    Re: Finding the name of a file Manfred <noname@add.invalid> - 2021-01-15 20:12 +0100
      Re: Finding the name of a file scott@slp53.sl.home (Scott Lurndal) - 2021-01-15 19:55 +0000
        Re: Finding the name of a file Manfred <noname@add.invalid> - 2021-01-16 02:06 +0100

Page 1 of 2  [1] 2  Next page →

#158297 — Finding the name of a file

Let assume that I have created a pointer to a File and I opened a file in some mode.
For example: FILE*  fp = fopen("example.txt", "r")
I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".

[toc] | [next] | [standalone]

#158299

On 12/01/2021 15:26, emanuele cannizzo wrote:
> Let assume that I have created a pointer to a File and I opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
> 

Not that I know of.

But you can try wrapping fopen and fclose functions with versions that 
store the file name (and mode if needed), with its file pointer, into a 
table: add it to the table on fopen, and remove it on fclose.

Then it is easy to write a new function that searches the table for the 
name that matches a particular file pointer.

(This won't work however with existing code that uses fopen/fclose that 
cannot be modified.)

[toc] | [prev] | [next] | [standalone]

#158306

Bart <bc@freeuk.com> writes:
>On 12/01/2021 15:26, emanuele cannizzo wrote:
>> Let assume that I have created a pointer to a File and I opened a file in some mode.
>> For example: FILE*  fp = fopen("example.txt", "r")
>> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
>> 
>
>Not that I know of.
>
>But you can try wrapping fopen and fclose functions with versions that 
>store the file name (and mode if needed), with its file pointer, into a 
>table: add it to the table on fopen, and remove it on fclose.
>
>Then it is easy to write a new function that searches the table for the 
>name that matches a particular file pointer.
>
>(This won't work however with existing code that uses fopen/fclose that 
>cannot be modified.)

Actually, it work just fine (for dynamically linked executables
on unix and linux systems, anyway).

Google "interposer library".

[toc] | [prev] | [next] | [standalone]

#158300

Am 12.01.2021 um 16:26 schrieb emanuele cannizzo:
> Let assume that I have created a pointer to a File and I opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".

Delete all files on your system until further operations
on your file fail (Unix).

[toc] | [prev] | [next] | [standalone]

#158307

=?UTF-8?Q?Christian_Hann=c3=a9?= <the.hanne@gmail.com> writes:
>Am 12.01.2021 um 16:26 schrieb emanuele cannizzo:
>> Let assume that I have created a pointer to a File and I opened a file in some mode.
>> For example: FILE*  fp = fopen("example.txt", "r")
>> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
>
>Delete all files on your system until further operations
>on your file fail (Unix).

Or just use 'lsof' (linux).

[toc] | [prev] | [next] | [standalone]

#158313

Christian Hann? <the.hanne@gmail.com> wrote:
> Am 12.01.2021 um 16:26 schrieb emanuele cannizzo:
> > Let assume that I have created a pointer to a File and I opened a file in some mode.
> > For example: FILE*  fp = fopen("example.txt", "r")
> > I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".
> 
> Delete all files on your system until further operations
> on your file fail (Unix).

AFAIK this does not work.  In fact if you want "invisible" file
standard trick is to open a file and just after that delete it.
As long as file is open it still exists on disk, but is
invisible to standard filesystem operations.  In particular
in traditional Unix there are no name that will give you
the file.  In Linux you probably can still get the file via

/proc/pid/fd/fdnum

where 'pid' is process id of your process and 'fdnum' is
file descriptor used to access the file.  But I am not
sure if OP would consider such thing as 'the name'.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#158301

On Tuesday, 12 January 2021 at 15:26:16 UTC, emaca...@gmail.com wrote:
> Let assume that I have created a pointer to a File and I opened a file in some mode. 
> For example: FILE* fp = fopen("example.txt", "r") 
> I want to know if there is any function that takes as parameter the file pointer fp and returns the name of the file "example.txt" and the mode "r".

The file may have multiple names if it's on unix-style filesystem 
and has multiple hard-links to it.

The file may not have a name if the file was opened and then unlinked
on such a file system. (I seem to recall that's a common technique for
temporary file handling).

So while there may be some mechanism to identify some name for an 
open file on some systems, I don't believe that in general it's available.

[toc] | [prev] | [next] | [standalone]

#158302

emanuele cannizzo:

> Let assume that I have created a pointer to a File and I
> opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as
> parameter the file pointer fp and returns the name of the
> file "example.txt" and the mode "r".

The apparent absence of such a function is inidicating a
problem in your design if you need it.  From the viewpoint
of single source of information, if you provided a filename
to fopen(), you know it already.

One non-portable way of obtaining the file name from FILE*
is to study the definition of the FILE structure and extract
it from there (if it is there at all...).

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158308

On Tuesday, 12 January 2021 at 16:41:58 UTC, Anton Shepelev wrote:
> emanuele cannizzo:
> > Let assume that I have created a pointer to a File and I 
> > opened a file in some mode. 
> > For example: FILE* fp = fopen("example.txt", "r") 
> > I want to know if there is any function that takes as 
> > parameter the file pointer fp and returns the name of the 
> > file "example.txt" and the mode "r".
> The apparent absence of such a function is inidicating a 
> problem in your design if you need it. From the viewpoint 
> of single source of information, if you provided a filename 
> to fopen(), you know it already. 
> 
Or a problem with the "information hiding" paradigm. The filename
is clearly present in the program, but might be buried deep down
in some sub-module. Another function deep down in an unrelated
module might need it for some non-core purpose, like error
reporting.

One answer is to break the information hiding by  storing the
filename in a global at the point you create it. Another answer is
to pass up and pass down. Neither is fully satisfactory.

However the FILE structure isn't usually tagged with the file's name,
so you can't retrieve it from a FILE *. You can do it yourself by
creating a list of FILE * / filename pairs which you fill at open time
and delete when the file is closed, but that's a lot of mutual
dependency and complexity to build in to a program.

[toc] | [prev] | [next] | [standalone]

#158310

Malcolm McLean:

> One answer is to break the information hiding by storing
> the filename in a global at the point you create it.
> Another answer is to pass up and pass down. Neither is
> fully satisfactory.

Yet the second one is safer and more future-proof. What if
you decide to move the code into a reusable library?

> However the FILE structure isn't usually tagged with the
> file's name, so you can't retrieve it from a FILE *. You
> can do it yourself by creating a list of FILE * / filename
> pairs which you fill at open time and delete when the file
> is closed, but that's a lot of mutual dependency and
> complexity to build in to a program.

As Bart suggested.  Yet this list would be another global
variable, with the same problems as above. My immediate
advice would be to wrap not only fopen(), but also
FILE* -- to store the filename:

   struct MYFILE
   {  FILE*     _    ; /* the system FILE pointer               */
      char[256] name ; /* whatever the maximum file name may be */
      char *    nameP; /* an alternative                        */
   };

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158303

emanuele cannizzo <emacannizzo@gmail.com> writes:

> Let assume that I have created a pointer to a File and I opened a file in some mode.
> For example: FILE*  fp = fopen("example.txt", "r")
> I want to know if there is any function that takes as parameter the
> file pointer fp and returns the name of the file "example.txt" and the
> mode "r".

Depending on the file system a file may not even have a unique name, so
this can be impossible even in principle (this is true of the "standard"
file systems under Linux).

There may be ways to get "a" filename; for instance, again under Linux
the file in /proc/proc/fd/<fd> is a symbolic link to the file currently
opened by the current process as file descripter <fd>.  You can also use
<pid> in place of "self" to look at the files held by process <pid>.
The symbolic link will be to the filename the descriptor was opened as.

[toc] | [prev] | [next] | [standalone]

#158304

On 12/01/2021 16:42, Joe Pfeiffer wrote:
> emanuele cannizzo <emacannizzo@gmail.com> writes:
> 
>> Let assume that I have created a pointer to a File and I opened a file in some mode.
>> For example: FILE*  fp = fopen("example.txt", "r")
>> I want to know if there is any function that takes as parameter the
>> file pointer fp and returns the name of the file "example.txt" and the
>> mode "r".
> 
> Depending on the file system a file may not even have a unique name, so
> this can be impossible even in principle (this is true of the "standard"
> file systems under Linux).

What's wrong with just returning the name that was passed to fopen()?

(I posted separately with a suggestion to wrap fopen/fclose with 
versions that retain that info, but the post has disappeared.)

[toc] | [prev] | [next] | [standalone]

#158305

Bart:

> (I posted separately with a suggestion to wrap
> fopen/fclose with versions that retain that info, but the
> post has disappeared.)

I can see it.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#158312

Bart <bc@freeuk.com> writes:

> On 12/01/2021 16:42, Joe Pfeiffer wrote:
>> emanuele cannizzo <emacannizzo@gmail.com> writes:
>> 
>>> Let assume that I have created a pointer to a File and I opened a
>>> file in some mode.
>>> For example: FILE*  fp = fopen("example.txt", "r")
>>> I want to know if there is any function that takes as parameter the
>>> file pointer fp and returns the name of the file "example.txt" and the
>>> mode "r".
>> Depending on the file system a file may not even have a unique name,
>> so
>> this can be impossible even in principle (this is true of the "standard"
>> file systems under Linux).
>
> What's wrong with just returning the name that was passed to fopen()?
>
> (I posted separately with a suggestion to wrap fopen/fclose with
> versions that retain that info, but the post has disappeared.)

I'm answering his question, not telling him why he shouldn't need to ask
it (but yes, the easiest and best thing to do is probably to to stash it
someplace while he does have it and then retrieve it as needed).

[toc] | [prev] | [next] | [standalone]

#158315

Bart <bc@freeuk.com> wrote:
> On 12/01/2021 16:42, Joe Pfeiffer wrote:
> > emanuele cannizzo <emacannizzo@gmail.com> writes:
> > 
> >> Let assume that I have created a pointer to a File and I opened a file in some mode.
> >> For example: FILE*  fp = fopen("example.txt", "r")
> >> I want to know if there is any function that takes as parameter the
> >> file pointer fp and returns the name of the file "example.txt" and the
> >> mode "r".
> > 
> > Depending on the file system a file may not even have a unique name, so
> > this can be impossible even in principle (this is true of the "standard"
> > file systems under Linux).
> 
> What's wrong with just returning the name that was passed to fopen()?

Depends what you want to do with the name.  If you want to pass
the name to another program P2 so that P2 can access the same
file, then in most cases 'proc' method is superior.  Trival advantage
is that 'proc' gives you access to deleted/renamed files
while using original name may fail.  If you want to show name
in error messages than your method is better.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#158316

On 12/01/2021 20:12, antispam@math.uni.wroc.pl wrote:
 > Bart <bc@freeuk.com> wrote:
 >> On 12/01/2021 16:42, Joe Pfeiffer wrote:
 >>> emanuele cannizzo <emacannizzo@gmail.com> writes:
 >>>
 >>>> Let assume that I have created a pointer to a File and I opened a 
file in some mode.
 >>>> For example: FILE*  fp = fopen("example.txt", "r")
 >>>> I want to know if there is any function that takes as parameter the
 >>>> file pointer fp and returns the name of the file "example.txt" and the
 >>>> mode "r".
 >>>
 >>> Depending on the file system a file may not even have a unique name, so
 >>> this can be impossible even in principle (this is true of the 
"standard"
 >>> file systems under Linux).
 >>
 >> What's wrong with just returning the name that was passed to fopen()?
 >
 > Depends what you want to do with the name.  If you want to pass
 > the name to another program P2 so that P2 can access the same
 > file, then in most cases 'proc' method is superior.

If the file name is relative, then the file you get may depend on the 
current directory etc. If that context can be different, then turn the 
relative file spec into an absolute one.

It still may not work because file names and paths may be deleted or be 
changed, or the file itself may be different anyway.

This is the same problem as opening and closing file A at one point in a 
program, then accessing file A again later on. It may or may not work, 
or yield a different file.

 >  Trival advantage
 > is that 'proc' gives you access to deleted/renamed files
 > while using original name may fail.

Is that an advantage? Usually you don't want a deleted file to be 
visible, and you want to rename file A to B so that you /can't/ access 
it as A.

[toc] | [prev] | [next] | [standalone]

#158322

Bart <bc@freeuk.com> wrote:
> On 12/01/2021 20:12, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 12/01/2021 16:42, Joe Pfeiffer wrote:
> >>> emanuele cannizzo <emacannizzo@gmail.com> writes:
> >>>
> >>>> Let assume that I have created a pointer to a File and I opened a 
> file in some mode.
> >>>> For example: FILE*  fp = fopen("example.txt", "r")
> >>>> I want to know if there is any function that takes as parameter the
> >>>> file pointer fp and returns the name of the file "example.txt" and the
> >>>> mode "r".
> >>>
> >>> Depending on the file system a file may not even have a unique name, so
> >>> this can be impossible even in principle (this is true of the 
> "standard"
> >>> file systems under Linux).
> >>
> >> What's wrong with just returning the name that was passed to fopen()?
> >
> > Depends what you want to do with the name.  If you want to pass
> > the name to another program P2 so that P2 can access the same
> > file, then in most cases 'proc' method is superior.
> 
> If the file name is relative, then the file you get may depend on the 
> current directory etc. If that context can be different, then turn the 
> relative file spec into an absolute one.
> 
> It still may not work because file names and paths may be deleted or be 
> changed, or the file itself may be different anyway.
> 
> This is the same problem as opening and closing file A at one point in a 
> program, then accessing file A again later on. It may or may not work, 
> or yield a different file.

Yes.  If you need to access "the same file", then you can try
workarounds like trying to get canonical name.  But is
reliable only if user can not change components of the name,
otherwise determined malicious user still manage to change
file pointed to by name (even when he/she can not change content
of the file).  Or you can use reliable (but system specific)
method.

> >  Trival advantage
> > is that 'proc' gives you access to deleted/renamed files
> > while using original name may fail.
> 
> Is that an advantage? Usually you don't want a deleted file to be 
> visible, and you want to rename file A to B so that you /can't/ access 
> it as A.
 
As I wrote, it depends on what you want.  I you want "the same
file", the 'proc' method can do this while normal names can not.
If you want "whatever file currently happens to be under
this name", then use normal name.

Just understand that files are different than file names.
Filesystem maps names to files.  What users perceive as
delete breaks association between name and file (and
operation is called 'unlink' to stress this aspect).
But even if you unlink all normal names file exists
as long as there are programs which keep it open.
File is really deleted when it is not accessible trough
filesystem and no program uses it.  This may look
like solipsism, but in fact give you nice warranties
of correctness.  For example, with some care you can
replace some critical system files while system is
running.  Simply programs started before update continue
to use old file, the ones started after update use
new file.  Eventually old file will be unused and
really deleted.  No nonsense like "reboot for update
to take effect". 

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#158328

antispam@math.uni.wroc.pl writes:
> Bart <bc@freeuk.com> wrote:
>> On 12/01/2021 20:12, antispam@math.uni.wroc.pl wrote:
>> > Bart <bc@freeuk.com> wrote:
>> >> On 12/01/2021 16:42, Joe Pfeiffer wrote:
>> >>> emanuele cannizzo <emacannizzo@gmail.com> writes:
>> >>>
>> >>>> Let assume that I have created a pointer to a File and I opened a 
>> file in some mode.
>> >>>> For example: FILE*  fp = fopen("example.txt", "r")
>> >>>> I want to know if there is any function that takes as parameter the
>> >>>> file pointer fp and returns the name of the file "example.txt" and the
>> >>>> mode "r".
>> >>>
>> >>> Depending on the file system a file may not even have a unique name, so
>> >>> this can be impossible even in principle (this is true of the 
>> "standard"
>> >>> file systems under Linux).
>> >>
>> >> What's wrong with just returning the name that was passed to fopen()?
>> >
>> > Depends what you want to do with the name.  If you want to pass
>> > the name to another program P2 so that P2 can access the same
>> > file, then in most cases 'proc' method is superior.
>> 
>> If the file name is relative, then the file you get may depend on the 
>> current directory etc. If that context can be different, then turn the 
>> relative file spec into an absolute one.
>> 
>> It still may not work because file names and paths may be deleted or be 
>> changed, or the file itself may be different anyway.
>> 
>> This is the same problem as opening and closing file A at one point in a 
>> program, then accessing file A again later on. It may or may not work, 
>> or yield a different file.
>
> Yes.  If you need to access "the same file", then you can try
> workarounds like trying to get canonical name.  But is
> reliable only if user can not change components of the name,
> otherwise determined malicious user still manage to change
> file pointed to by name (even when he/she can not change content
> of the file).  Or you can use reliable (but system specific)
> method.
>
>> >  Trival advantage
>> > is that 'proc' gives you access to deleted/renamed files
>> > while using original name may fail.
>> 
>> Is that an advantage? Usually you don't want a deleted file to be 
>> visible, and you want to rename file A to B so that you /can't/ access 
>> it as A.
>  
> As I wrote, it depends on what you want.  I you want "the same
> file", the 'proc' method can do this while normal names can not.
> If you want "whatever file currently happens to be under
> this name", then use normal name.
>
> Just understand that files are different than file names.
> Filesystem maps names to files.  What users perceive as
> delete breaks association between name and file (and
> operation is called 'unlink' to stress this aspect).
> But even if you unlink all normal names file exists
> as long as there are programs which keep it open.
> File is really deleted when it is not accessible trough
> filesystem and no program uses it.  This may look
> like solipsism, but in fact give you nice warranties
> of correctness.  For example, with some care you can
> replace some critical system files while system is
> running.  Simply programs started before update continue
> to use old file, the ones started after update use
> new file.  Eventually old file will be unused and
> really deleted.  No nonsense like "reboot for update
> to take effect". 

To be clear, this is true of Unix-like systems (and /proc is more or
less Linux-specific, though some other Unix-like systems may support
it).  The original post in this thread didn't specify an operating
system or file system.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#158364

On Tue, 2021-01-12, Keith Thompson wrote:
...
> To be clear, this is true of Unix-like systems (and /proc is more or
> less Linux-specific, though some other Unix-like systems may support
> it).  The original post in this thread didn't specify an operating
> system or file system.

The OP was simply asking about the standard C library, if there is
a name_of(FILE*).  And there isn't, so the thread could have stopped
right there.

When you're starting to suggest workarounds, you have to make
assumptions about what it's going to be used for, and about the
OS.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#158375

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Tue, 2021-01-12, Keith Thompson wrote:
> ...
>
>> To be clear, this is true of Unix-like systems (and /proc is more or
>> less Linux-specific, though some other Unix-like systems may support
>> it).  The original post in this thread didn't specify an operating
>> system or file system.
>
> The OP was simply asking about the standard C library, if there is
> a name_of(FILE*).  [...]

The top-of-thread posting that I saw said this (some white space
added):

    Let assume that I have created a pointer to a File and
    I opened a file in some mode.

    For example:  FILE*  fp = fopen("example.txt", "r")

    I want to know if there is any function that takes as
    parameter the file pointer fp and returns the name of
    the file "example.txt" and the mode "r".

I don't see anything there that says he is asking (only) about
the standard C library.  What he wants to know is about "any
function".  Are you referring to some other comment that I may
have missed?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web