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 *);

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

On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> 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 *.
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 *FileNameFromFileP(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...

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 *FileNameFromFileP(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; 

In article <g3ghbs$j5j$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:

>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

vippstar@gmail.com wrote:
> On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> 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 *.
> 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 *FileNameFromFileP(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

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.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

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 *FileNameFromFileP(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

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

On Jun 20, 7:00 pm, jacob navia <ja...@nospam.com> wrote:
> vipps...@gmail.com wrote:
> > On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> 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 *.
> > 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 *FileNameFromFileP(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.

On Jun 20, 7:08 pm, jacob navia <ja...@nospam.com> wrote:
> 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

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 *FileNameFromFileP(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/>

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 *FileNameFromFileP(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

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

jacob navia <jacob@nospam.com> writes:
> 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 *);

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_Keith) 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"

On Jun 20, 9:41 am, Eric Sosman <Eric.Sos...@sun.com> wrote:
> 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

mingyanguo wrote:
> 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.

1) It is not difficult at all to see if the name still matches
    the contents of the file. Open the file with that name
    and compare the first bytes... If the data matches with the
    data in the still opened original file they are the same.
    That would make you immune against this quite rare problem.

2) Under windows it is not possible to erase a file that is
    already open by another process, as far as I know. If
    under Unix, you have to take care that when you get the
    file name you should not assume that the file is still there.
    All this is not the problem of fopen.
> So, remembering the file name for a FILE rarely makes sense.

It makes sense in most applications, specially when you write
a library and you receive a FILE pointer, and you want to
write a more comprehensible error message than:
	fprintf(stderr,"Can't write to file %p\n",file);

There will be no guarantee that the file name is unique, that
the file name corresponds to a still existing file, etc. It will be
just the argument you passed to fopen!

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> mingyanguo wrote:
[ ... ]
>> So, remembering the file name for a FILE rarely makes sense.
> 
> It makes sense in most applications, specially when you write
> a library and you receive a FILE pointer, and you want to
> write a more comprehensible error message than:
> fprintf(stderr,"Can't write to file %p\n",file);

You can have your library function take an additional char * parameter
specifying the file name, which the caller will surely be knowing.

<snip>

Keith Thompson wrote, On 20/06/08 18:29:
> jacob navia <jacob@nospam.com> writes:
>> 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 *);
> 
> I mildly prefer "fname".  I strongly suggest that it *not* be declared
> in <stdio.h>, even in non-conforming mode.

It would certainly break lots of SW I have access to. I would vote for 
__fname.

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

<snip>

You can play the game with DOS to a degree. If you could the path as 
part of the name you can definitely do this with Windows on NTFS.

Or the name you opened it with might not be the real name just a pointer 
to it.
-- 
Flash Gordon

vippstar@gmail.com wrote:
> 
> On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> wrote:
[... getting filename from 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...

And what would FunctionToGetFilenameFromFilePointer(stdout) return?

(I suppose "this function returns NULL if the filename cannot be
determined" may suffice here.)

BTW, we "solved" this for our own library by putting wrappers around
fopen/fclose (as well as open/close) to keep track of filenames for
files which we open.  This allows, for example, error messages to
include the filename.

[...]

-- 
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody        | www.hvcomputer.com | #include              |
| kenbrody/at\spamcop.net | www.fptech.com     |    <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

jacob navia wrote:
> 
> vippstar@gmail.com wrote:
> > On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> 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 *.
> > What should it return for tempfile(), stdin, stdout, stderr?
> 
> For tempfile() should return... the name of the temporary file of course

What if the file doesn't have a name?  Some implementations of
tmpfile() work by creating and opening a file, and then deleting
the file while still open.  The filename used to create the file
is no longer valid, and creating a file with that same name will
create a different file.

> For stdin it will return an invalid file name (either NULL or
> "....stdin...." or similar.

NULL would be better IMO, as it's easier to check for "failure",
and calling fopen("...stdin...","r") won't do what you want.

[...]

-- 
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody        | www.hvcomputer.com | #include              |
| kenbrody/at\spamcop.net | www.fptech.com     |    <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

jacob navia wrote:
> mingyanguo wrote:
>> 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.
> 
> 1) It is not difficult at all to see if the name still matches
>    the contents of the file. Open the file with that name
>    and compare the first bytes... If the data matches with the
>    data in the still opened original file they are the same.
>    That would make you immune against this quite rare problem.

     It's not rare at all, and the test is not reliable.  One
scenario where this happens is in an editor that reads a file
into memory, massages it, and then wants to save the modified
version.  Instead of overwriting the original file, which risks
catastrophic data loss if there's an ill-timed crash or I/O
failure or something, the editor may write to a temporary file,
then remove the original and rename the temporary:

	data = loadData("file.dat");
	massage(data);
	saveData("file.tmp", data);
	remove("file.dat"); // or rename("file.dat", "file.old")
	rename("file.tmp", "file.dat");

     Of course, if the programmer used the editor to make a
change near the end of a long file while leaving the first
ten thousand lines intact, comparing only "the first bytes"
is not sufficient.

> 2) Under windows it is not possible to erase a file that is
>    already open by another process, as far as I know. If
>    under Unix, you have to take care that when you get the
>    file name you should not assume that the file is still there.
>    All this is not the problem of fopen.
>> So, remembering the file name for a FILE rarely makes sense.
> 
> It makes sense in most applications, specially when you write
> a library and you receive a FILE pointer, and you want to
> write a more comprehensible error message than:
>     fprintf(stderr,"Can't write to file %p\n",file);

     My own preference is for libraries that don't write such
messages, but instead pass the details of failures and such
upwards to their callers.  The callers can then choose whether
to write to stderr -- or to open a dialog box, or send a text
message to somebody's pager, or make an entry in the system
logging service, or ...

> There will be no guarantee that the file name is unique, that
> the file name corresponds to a still existing file, etc. It will be
> just the argument you passed to fopen!

     Hence, useful only for "decorative" purposes.  That's fine,
but it's not a feature that appears to add a lot of value.
(Which is good news, in a way, because it lets you get away
with a "close enough for jazz" effort.  This is one of those
situations where doing a ninety-percent job is trivial but
doing a hundred-percent job is damn' near impossible.)

-- 
Eric.Sosman@sun.com

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?

_fname


> What problems could arise with this function? 

Non-portable code.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad 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?
> 
> _fname
> 
> 

Yes, it is better with the underscore

>> What problems could arise with this function? 
> 
> Non-portable code.
> 

That is not a problem with the function.

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Walter Roberson wrote:
> In article <g3ghbs$j5j$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:
> 
>> 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 file name is the first parameter of the
fopen call. No matter what that is. That will
be returned.

Easy isn't it?

fopen remembers the file name, and that is what you get

WYGIWYO

What You Get Is What You Opened!


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Fri, 20 Jun 2008 23:03:33 +0200, jacob navia wrote:
> Walter Roberson wrote:
>> In article <g3ghbs$j5j$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:
>> 
>>> 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 file name is the first parameter of the
> fopen call. No matter what that is. That will
> be returned.
> 
> Easy isn't it?
> 
> fopen remembers the file name, and that is what you get
> 
> WYGIWYO
> 
> What You Get Is What You Opened!

This sounds like a terrible idea to me. Consider a program that opens tens
of thousands of files simultaneously, all with long filenames, say 100 or
200 bytes each. You could easily be wasting 1MB or more just storing
copies of all the filenames in your standard library.

In article <pan.2008.06.20.21.22.42.828174@spam.com>,
Chris Peters  <no@spam.com> wrote:

>Consider a program that opens tens
>of thousands of files simultaneously, all with long filenames, say 100 or
>200 bytes each. You could easily be wasting 1MB or more just storing
>copies of all the filenames in your standard library.

As Jacob is writing the implementation of fopen(), he could choose to
limit the number of simultaneously open files, possibly even according
to whether he has "room" to store the new filename (though he
wouldn't want to get into compacting out holes in a static name
array, as that could end up moving filenames around after the name
pointer had already been made available to to program.)

On POSIX systems, the minimum maximum number of simultaneous open
files is just 16. 200 or 255 are common (traditionally the file
descriptor number was a single byte.)

Checking around a bit, I see that the default hard limit in NT
is 10000 files, and that apparently for some people that's a problem.
Odd. It's alterable, apparently,
http://support.microsoft.com/kb/326591/en-us
There's a mention of NetDDE (Dynamic Data Exchange) as being an
example of when it could be a problem. On the other hand,
NetDDE was removed from Windows Vista, it appears
http://en.wikipedia.org/wiki/Dynamic_Data_Exchange

-- 
  "Let me live in my house by the side of the road --
   It's here the race of men go by.
   They are good, they are bad, they are weak, they are strong
   Wise, foolish -- so am I;"                 -- Sam Walter Foss

Chris Peters wrote:
> On Fri, 20 Jun 2008 23:03:33 +0200, jacob navia wrote:
>> What You Get Is What You Opened!
> 
> This sounds like a terrible idea to me. Consider a program that opens tens
> of thousands of files simultaneously, all with long filenames, say 100 or
> 200 bytes each. You could easily be wasting 1MB or more just storing
> copies of all the filenames in your standard library.
> 

If you open 10 thousand files  with each a name of
256 chars, you get 256*10000-->2 560 000 bytes,
2MB.

Nothing for a machine that can open 10 000 files simultaneously.

Those machines have now routinely 1GB installed.

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Jun 20, 7:14=A0pm, jacob navia <ja...@nospam.com> wrote:

> 1) It is not difficult at all to see if the name still matches
> =A0 =A0 the contents of the file. Open the file with that name
> =A0 =A0 and compare the first bytes... If the data matches with the
> =A0 =A0 data in the still opened original file they are the same.
> =A0 =A0 That would make you immune against this quite rare problem.

That is pathetic. The customary way of updating files in MacOS X is to
write a copy of the modified file, then using a (non-standard C) call
to exchange the original and the modified file, and finally deleting
the original. If application B does that while your application A does
its clever thing, data loss is inevitable.

> 2) Under windows it is not possible to erase a file that is
> =A0 =A0 already open by another process, as far as I know. If
> =A0 =A0 under Unix, you have to take care that when you get the
> =A0 =A0 file name you should not assume that the file is still there.
> =A0 =A0 All this is not the problem of fopen.

You should really get used to looking a bit further than Windows.

What you are suggesting is in the end a function that returns the name
that was used to open a file, not the name of the file. That is
trivial to implement for anyone who wants it, and not very useful. If
you can implement a function that will either return the _correct_
name of a file or determine that there is no name, go ahead and do it.

jacob navia <jacob@nospam.com> writes:
[...]
> The file name is the first parameter of the
> fopen call. No matter what that is. That will
> be returned.
>
> Easy isn't it?
[...]

Not really.

What if the file wasn't opened via fopen()?

Among standard functions, tmpfile() and freopen() probably aren't much
of a problem, but you at least need to think about them.

There might be more serious problems if you support non-standard
functions that return FILE* results (popen(), for example).

(In your initial description, you mentioned "lower case"; re-reading
it, I think you were referring to the name "fopen", not to the result
it returns.)

-- 
Keith Thompson (The_Other_Keith) 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"

In article <g3gs1q$r46$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:

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

>1) It is not difficult at all to see if the name still matches
>    the contents of the file. Open the file with that name
>    and compare the first bytes... If the data matches with the
>    data in the still opened original file they are the same.
>    That would make you immune against this quite rare problem.

But why would you want to do this at all?  If you already have the
file open, why open it again?  Just what is the problem you are trying
to solve?

The most obvious use for having the file name is to give better error
messages (as in your example), and for that none of these issues are
important.  So long as users understand the limited uses of the file
name, it seems like a handy addition.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

jacob navia wrote:
> 
> 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 *);
> 
> What problems could arise with this function? Why is not in the
> C API?

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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

In article <e4589517-08df-41c9-81a8-7a150ef2781e@a70g2000hsh.googlegroups.com>,
christian.bau <christian.bau@cbau.wanadoo.co.uk> wrote:

>You should really get used to looking a bit further than Windows.

If you're selling a compiler that only works with Windows, it doesn't
matter that your extensions rely on Windoziness.

>What you are suggesting is in the end a function that returns the name
>that was used to open a file, not the name of the file. That is
>trivial to implement for anyone who wants it, and not very useful.

It's very useful for producing better error messages, and can't be
reasonably implemented by the user without changing existing
interfaces.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

In article <pan.2008.06.20.21.22.42.828174@spam.com>,
Chris Peters  <no@spam.com> wrote:

>This sounds like a terrible idea to me. Consider a program that opens tens
>of thousands of files simultaneously, all with long filenames, say 100 or
>200 bytes each. You could easily be wasting 1MB or more just storing
>copies of all the filenames in your standard library.

And each of them quite likely has a buffer associated with it.  By
comparison the filename is unlikely to be significant, and of course
most filenames aren't anything like 200 bytes.

A more important limitation, mentioned in various forms by other
posters, is that many files just aren't opened by fopen() in the
current process.  They're inherited, or are pipes or sockets or
who-knows-what.  But perhaps that's rarer in Windows, and in any case
it's handy to have the filename for those cases where it is possible.

-- Richard

-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Richard Tobin wrote:
> In article <e4589517-08df-41c9-81a8-7a150ef2781e@a70g2000hsh.googlegroups.com>,
> christian.bau <christian.bau@cbau.wanadoo.co.uk> wrote:
> 
>> You should really get used to looking a bit further than Windows.
> 
> If you're selling a compiler that only works with Windows, it doesn't
> matter that your extensions rely on Windoziness.

Until you try to port either the compiler or the code that builds with
it.  Sounds like M$ standard practice :)

-- 
Ian Collins.

CBFalconer <cbfalconer@yahoo.com> writes:

> jacob navia wrote:
>> 
>> 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 *);
>> 
>> What problems could arise with this function? Why is not in the
>> C API?
>
> 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.

There is no such OS as Winders as far as I know. Please refrain from
using silly slang in a technical news group - as you frequently remind
others.

"christian.bau" wrote:
> 
.... snip ...
> 
> What you are suggesting is in the end a function that returns the
> name that was used to open a file, not the name of the file. That
> is trivial to implement for anyone who wants it, and not very
> useful. If you can implement a function that will either return
> the _correct_ name of a file or determine that there is no name,
> go ahead and do it.

That last is impossible under Unix/Linux.  A file, and its storage,
is specified separately from directory entries.  Any directory
entry may be linked to that file.  It can then be used to open the
file, read from it, write to it, etc. (depending on permissions). 
Those are known as links.  When the last link is deleted that file
is no longer accessible, and the system deletes it.  Users don't
delete files, they delete links.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

jacob navia wrote:
> Walter Roberson wrote:
>
.... snip ...
>
>> 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 file name is the first parameter of the fopen call. No matter
> what that is. That will be returned.  Easy isn't it?
> 
> fopen remembers the file name, and that is what you get

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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

"jacob navia" <jacob@nospam.com> schreef in bericht 
news:g3ghbs$j5j$1@aioe.org...
> What problems could arise with this function? Why is not in the C API?

I wouldn't put this in libc, it's something people can add themselves easily 
when they need it.

But anyway, how will you store the strings? You cant store pointers so you 
have to go for string copying. But how large will you make the arrays you 
will copy the names into? And will you provide a wide char version too for 
consistency?

In article <cc5e9$485d14c1$541fc2ec$13064@cache2.tilbu1.nb.home.nl>,
Serve Lau <nihao@qinqin.com> wrote:

>But anyway, how will you store the strings? You cant store pointers so you 
>have to go for string copying. But how large will you make the arrays you 
>will copy the names into?

How about the right length?  Are you suggesting that there's some
reason why fopen() shouldn't malloc() the space?

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

"Richard Tobin" <richard@cogsci.ed.ac.uk> schreef in bericht 
news:g3j9aq$14pa$1@pc-news.cogsci.ed.ac.uk...
> In article <cc5e9$485d14c1$541fc2ec$13064@cache2.tilbu1.nb.home.nl>,
> Serve Lau <nihao@qinqin.com> wrote:
>
>>But anyway, how will you store the strings? You cant store pointers so you
>>have to go for string copying. But how large will you make the arrays you
>>will copy the names into?
>
> How about the right length?  Are you suggesting that there's some
> reason why fopen() shouldn't malloc() the space?

That will require more knowledge of internal workings of standard C 
functions which is IMO never a good thing.

jacob navia skrev:
> Tor Rustad wrote:
>> 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.


>>> What problems could arise with this function? 
>>
>> Non-portable code.
>>
> 
> That is not a problem with the function.

 From the point of a user, unless we talk about throw away programs, 
it's a major problem if code can only be compiled with one compiler. In 
lcc-win case, who knows how long that particular compiler will be supported?


When I write non-portable code, it does something useful. Typically, the 
problem at hand, can't be solved via portable methods. I suspect you are 
wasting your time, by implementing this feature.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

In article <9ceb$485d2ad8$541fc2ec$12152@cache2.tilbu1.nb.home.nl>,

>>>But anyway, how will you store the strings? You cant store pointers so you
>>>have to go for string copying. But how large will you make the arrays you
>>>will copy the names into?

>> How about the right length?  Are you suggesting that there's some
>> reason why fopen() shouldn't malloc() the space?

>That will require more knowledge of internal workings of standard C 
>functions which is IMO never a good thing.

I'm baffled.  Aren't we talking about Jacob's implementation?
He's the implementor of the functions, he's supposed to know
about their internal workings.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Serve Lau wrote:
> 
> But anyway, how will you store the strings? You cant store pointers so 
> you have to go for string copying. But how large will you make the 
> arrays you will copy the names into? And will you provide a wide char 
> version too for consistency?
> 

I *can* store pointers.

fopen:

File->FileName = strdup(fname);

fclose:
free(File->FileName);



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Serve Lau wrote:

> "Richard Tobin" <richard@cogsci.ed.ac.uk> schreef in bericht 
>> How about the right length?  Are you suggesting that there's some
>> reason why fopen() shouldn't malloc() the space?
> 
> That will require more knowledge of internal workings of standard C 
> functions which is IMO never a good thing.

What knowledge of internal workings am I required to know for writing:
#include <stdlib.h>
char *s = NULL;
void foo(char *bar) {if (s = malloc(strlen(bar)+1)) strcpy(s, bar);}

Besides, the implementor of fopen() really should have knowledge of
the internal working of standard C functions like fgetc, fwrite, etc.

Ralf

In article <g3j9aq$14pa$1@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>In article <cc5e9$485d14c1$541fc2ec$13064@cache2.tilbu1.nb.home.nl>,
>Serve Lau <nihao@qinqin.com> wrote:

>>But anyway, how will you store the strings? You cant store pointers so you 
>>have to go for string copying. But how large will you make the arrays you 
>>will copy the names into?

>How about the right length?  Are you suggesting that there's some
>reason why fopen() shouldn't malloc() the space?

I do not have my C89 hardcopy here to check against. I know that there
are various routines that are marked with wording similar to
"The implementation shall behave as if no library routine
calls <name>". I do not recall if malloc() is one of those routines ?
-- 
  "They called it golf because all the other four letter words
  were taken."                                    -- Walter Hagen

Walter Roberson wrote:
> In article <g3j9aq$14pa$1@pc-news.cogsci.ed.ac.uk>,
> Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>> In article <cc5e9$485d14c1$541fc2ec$13064@cache2.tilbu1.nb.home.nl>,
>> Serve Lau <nihao@qinqin.com> wrote:
> 
>>> But anyway, how will you store the strings? You cant store pointers so you 
>>> have to go for string copying. But how large will you make the arrays you 
>>> will copy the names into?
> 
>> How about the right length?  Are you suggesting that there's some
>> reason why fopen() shouldn't malloc() the space?
> 
> I do not have my C89 hardcopy here to check against. I know that there
> are various routines that are marked with wording similar to
> "The implementation shall behave as if no library routine
> calls <name>". I do not recall if malloc() is one of those routines ?

     No, it is not.  Lots of fopen() implementations, for
example, obtain I/O buffers from malloc().

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

"Richard Tobin" <richard@cogsci.ed.ac.uk> schreef in bericht 
news:g3jf6m$16ia$1@pc-news.cogsci.ed.ac.uk...
> In article <9ceb$485d2ad8$541fc2ec$12152@cache2.tilbu1.nb.home.nl>,
>
>>>>But anyway, how will you store the strings? You cant store pointers so 
>>>>you
>>>>have to go for string copying. But how large will you make the arrays 
>>>>you
>>>>will copy the names into?
>
>>> How about the right length?  Are you suggesting that there's some
>>> reason why fopen() shouldn't malloc() the space?
>
>>That will require more knowledge of internal workings of standard C
>>functions which is IMO never a good thing.
>
> I'm baffled.  Aren't we talking about Jacob's implementation?
> He's the implementor of the functions, he's supposed to know
> about their internal workings.

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

"jacob navia" <jacob@nospam.com> schreef in bericht 
news:g3jfmi$oaf$1@aioe.org...
> Serve Lau wrote:
>>
>> But anyway, how will you store the strings? You cant store pointers so 
>> you have to go for string copying. But how large will you make the arrays 
>> you will copy the names into? And will you provide a wide char version 
>> too for consistency?
>>
>
> I *can* store pointers.
>
> fopen:
>
> File->FileName = strdup(fname);
>
> fclose:
> free(File->FileName);

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

>
>
>
> -- 
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatique
> http://www.cs.virginia.edu/~lcc-win32 

Walter Roberson wrote:

> The implementation shall behave as if no library routine
> calls

From n1256:

7.11.1.1(5)
The implementation shall behave as if no library function calls the
setlocale function.

7.11.2.1(7)
The implementation shall behave as if no library function calls the
localeconv function.

7.14.1.1(7)
The implementation shall behave as if no library function calls the
signal function.

7.19.4.4(4)
The implementation shall behave as if no library function calls the
tmpnam function.

7.20.2.1(3)
The implementation shall behave as if no library function calls the rand
function.

7.20.2.2(3)
The implementation shall behave as if no library function calls the
srand function.

7.20.4.5(3)
The implementation shall behave as if no library function calls the
getenv function.

7.20.7.1(3)
The implementation shall behave as if no library function calls the
mblen function.

7.20.7.2(3)
The implementation shall behave as if no library function calls the
mbtowc function.

7.20.7.3(3)
The implementation shall behave as if no library function calls the
wctomb function.

7.21.5.8(6)
The implementation shall behave as if no library function calls the
strtok function.

7.21.6.2(3)
The implementation shall behave as if no library function calls the
strerror function.

7.24.6.3(1)
Restartable multibyte/wide character conversion functions
[ ... ]
The implementation behaves as if no library function calls these
functions with a null pointer for ps.

7.24.6.4(1)
Restartable multibyte/wide string conversion functions.
[ ... ]
The implementation behaves as if no library function calls these
functions with a null pointer for ps.

In article <19331$485d5894$541fc2ec$15819@cache5.tilbu1.nb.home.nl>,
Serve Lau <nihao@qinqin.com> wrote:

>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
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Richard Tobin wrote:
> In article <19331$485d5894$541fc2ec$15819@cache5.tilbu1.nb.home.nl>,
> Serve Lau <nihao@qinqin.com> wrote:
> 
>> 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

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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Serve Lau wrote:
> 
> "jacob navia" <jacob@nospam.com> schreef in bericht 
> news:g3jfmi$oaf$1@aioe.org...
>> Serve Lau wrote:
>>>
>>> But anyway, how will you store the strings? You cant store pointers 
>>> so you have to go for string copying. But how large will you make the 
>>> arrays you will copy the names into? And will you provide a wide char 
>>> version too for consistency?
>>>
>>
>> I *can* store pointers.
>>
>> fopen:
>>
>> File->FileName = strdup(fname);
>>
>> fclose:
>> free(File->FileName);
> 
> 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

:-)


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <g3jsea$58o$3@aioe.org>, jacob navia  <jacob@nospam.org> wrote:

>>> 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 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
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

jacob navia said:

> Serve Lau wrote:
 
<snip>
 
>> 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?

So the programmer can't rely on _fname or whatever you decide to call it, 
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.

>> 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
 
You should avoid sarcasm, because you're no good at it. You have missed his 
point, which is that when a user (user-programmer, that is) tries to 
allocate a buffer for a filename copy and fails, he can tell right there 
that he's failed, and at that point he knows perfectly well that the 
failure is to do with memory allocation, not to do with a lack of 
available filename through some other cause (e.g. it's a pipe, socket, 
std*, or something along those lines).

You're supposed to be able to think of these issues yourself. If you can't, 
you're at least supposed to be able to recognise them as issues when other 
people raise them. You gain no credit when you attempt to ridicule other 
people for doing the thinking you should have been doing yourself.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> jacob navia said:
> 
>> Serve Lau wrote:
>  
> <snip>
>  
>>> 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?
> 
> 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.


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia said:

> Richard Heathfield wrote:
>> jacob navia said:
>> 
>>> Serve Lau wrote:
>>  
>> <snip>
>>  
>>>> 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?
>> 
>> 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...

Right.

> It could be that there is no
> more memory to allocate the FILE structure.

Right again.

> So, following
> your logic he should try to open the file himself and
> go directly through the OS routines.
> 
> Why bother with fopen?

Because by using fopen, he gains portability at the expense of being unable 
to make the distinction you mention. Since you are posting in comp.lang.c 
I presume you recognise the importance of portability (although why I 
presume this, in the face of all the contrary evidence, is beyond me).

<snip>
 
> Obvious. Just do not use lcc-win

That's good advice.

> do not pollute the threads I start.

If you don't want people to post replies to your articles, don't post 
articles. Duh.

> Just GO AWAY!

Ever heard of freedom of speech? If you must be a witless fool, go ahead, 
but don't expect others to put up with it silently.

> [snip]
> 
>> You should avoid sarcasm, because you're no good at it.
> 
> Did I ask for any advice?

No, and that is why you fail.

> Keep it for yourself.

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

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"jacob navia" <jacob@nospam.com> schreef in bericht 
news:g3jucg$d04$1@aioe.org...
> 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.

On Jun 20, 9:11=A0am, jacob navia <ja...@nospam.com> 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:
> =A0 =A0 =A0 =A0 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?
> =A0 =A0 =A0 =A0 char *fname(FILE *); // lower case, short, similar to oth=
er
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // file funct=
ions
>
> =A0 =A0 =A0 =A0 // clear name but maybe too long?
> =A0 =A0 =A0 =A0 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.

Tor Rustad <tor_rustad@hotmail.com> writes:
> jacob navia skrev:
>> Tor Rustad wrote:
>>> 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_Other_Keith) 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"

[Last paragraph duplicated here to clarify why I am posting this reply.]

Keith Thompson said:

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

Glad to oblige (although I think you're wasting your time).

Keith's full article follows.

Keith Thompson said:

> Tor Rustad <tor_rustad@hotmail.com> writes:
>> jacob navia skrev:
>>> Tor Rustad wrote:
>>>> 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?

No further comment.

> 

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

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

jacob navia wrote:
> 
> 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 *);
> 
> What problems could arise with this function? Why is not in the
> C API?

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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

forkazoo wrote:
> jacob navia <ja...@nospam.com> wrote:
>
>> 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 *.
>
.... snip ...
> 
> 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.

ISO won't.  The function is impossible on many common OSs, such as
Linux, Unix, Posix (generic), etc.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

Keith Thompson skrev:
> Tor Rustad <tor_rustad@hotmail.com> writes:
>> jacob navia skrev:
>>> Tor Rustad wrote:
>>>> 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.

I have never used lcc-win, but Jacob said:

"We are rewriting the libc for the 64 bit version of lcc-win"

so I assume this function will be in libc, and then there might be 
collisions during linking, even if 'fname' isn't in one of the standard 
headers.


The linker can resolve this, but will under e.g. GCC issue a warning:

$ cat use_libc_sym.c
#include <stdio.h>

static void malloc(void)
{
         printf("User supplied malloc\n");
}

int main(void)
{
         malloc();

         return 0;
}
$ gcc -ansi -pedantic -Wall use_libc_sym.c
use_libc_sym.c:4: warning: conflicting types for built-in function �malloc�
$ ./a.out
User supplied malloc


so I suggest using an underscore prefix '_fname', regardless of which 
header file to be used.


> 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?

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

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

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

Tor Rustad <tor_rustad@hotmail.com> writes:
> 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.

-- 
Keith Thompson (The_Other_Keith) 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"

On Jun 20, 10:11 am, jacob navia <ja...@nospam.com> 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 *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>

"Serve Lau" <nihao@qinqin.com> wrote in message 
news:c8164$485daf34$541fc2ec$19083@cache5.tilbu1.nb.home.nl...
>
> "jacob navia" <jacob@nospam.com> schreef in bericht 
> news:g3jucg$d04$1@aioe.org...
>> 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.

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.

-- 
Bartc 

CBFalconer <cbfalconer@yahoo.com> wrote:

> jacob navia wrote:
> > fopen remembers the file name, and that is what you get
> 
> 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.

On 22 Jun, 02:47, "Serve Lau" <ni...@qinqin.com> wrote:
> "jacob navia" <ja...@nospam.com> schreef in berichtnews:g3jucg$d04$1@aioe.org...

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

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>

--
Nick Keighley

In article <5dbfb650-6dd9-446e-b509-777128c690d0@c58g2000hsc.googlegroups.com>,
Nick Keighley  <nick_keighley_nospam@hotmail.com> wrote:

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

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

-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Richard Heathfield <rjh@see.sig.invalid> writes:

> jacob navia said:
>
>> Keep it for yourself.
>
> 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?

CBFalconer <cbfalconer@yahoo.com> writes:

> Nobody seems to have noticed this objection to the idea.  Repost.
>
> jacob navia wrote:
>> 
>> 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 *);
>> 
>> What problems could arise with this function? Why is not in the
>> C API?
>
> 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"?

Richard wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
> 
>> Nobody seems to have noticed this objection to the idea.  Repost.
>>
>> jacob navia wrote:
>>> 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 *);
>>>
>>> What problems could arise with this function? Why is not in the
>>> C API?
>> 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"?

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


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Jun 23, 6:09 am, jacob navia <ja...@nospam.com> wrote:
> Richard wrote:
> > CBFalconer <cbfalco...@yahoo.com> writes:
>
> >> Nobody seems to have noticed this objection to the idea.  Repost.
>
> >> jacob navia wrote:
> >>> 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 *);
>
> >>> What problems could arise with this function? Why is not in the
> >>> C API?
> >> 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"?
>
> Must be HIS OS of course. It is surely a good fit for him
>
> --
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

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?

John Bode wrote:
> On Jun 23, 6:09 am, jacob navia <ja...@nospam.com> wrote:
>> Richard wrote:
>>> CBFalconer <cbfalco...@yahoo.com> writes:
>>>> Nobody seems to have noticed this objection to the idea.  Repost.
>>>> jacob navia wrote:
>>>>> 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 *);
>>>>> What problems could arise with this function? Why is not in the
>>>>> C API?
>>>> 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"?
>> Must be HIS OS of course. It is surely a good fit for him
>>
>> --
>> jacob navia
>> jacob at jacob point remcomp point fr
>> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32
> 
> 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

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

John Bode <jfbode1029@gmail.com> writes:

> On Jun 23, 6:09 am, jacob navia <ja...@nospam.com> wrote:
>> Richard wrote:
>> > CBFalconer <cbfalco...@yahoo.com> writes:
>>
>> >> Nobody seems to have noticed this objection to the idea.  Repost.
>>
>> >> jacob navia wrote:
>> >>> 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 *);
>>
>> >>> What problems could arise with this function? Why is not in the
>> >>> C API?
>> >> 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"?
>>
>> Must be HIS OS of course. It is surely a good fit for him
>>
<sig block snipped>

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

-- 
Ben.

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:87y74wp5x9.fsf@bsb.me.uk...
> John Bode <jfbode1029@gmail.com> writes:

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

Sounds very dangerous to just store a pointer. The original argument may 
have pointed to a temporary value. Or to a local variable now out of scope. 
Or to a buffer now with different contents.

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

Since lccwin is for Windows there is already an OS-specific call to obtain 
the normalised (as I term it) form of the file.

-- 
Bartc 

In comp.lang.c, jacob navia wrote:

> vippstar@gmail.com wrote:
>> On Jun 20, 6:11 pm, jacob navia <ja...@nospam.com> 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 *.
>> 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.

What if stdin, stdout, or stderr have been redirected to a file? As in

  Microsoft Windows XP [Version 5.1.2600]
  (C) Copyright 1985-2001 Microsoft Corp.
  C:\Documents and Settings\Guest>md temp
  C:\Documents and Settings\Guest>cd temp
  C:\Documents and Settings\Guest\temp>dir >thisfile.txt
  C:\Documents and Settings\Guest\temp>type thisfile.txt
   Volume in drive C has no label.
   Volume Serial Number is 061E-1ADD
  
   Directory of C:\Documents and Settings\Guest\temp
  
  06/23/2008  11:15 AM    <DIR>          .
  06/23/2008  11:15 AM    <DIR>          ..
  06/23/2008  11:16 AM                 0 thisfile.txt
                 1 File(s)              0 bytes
                 2 Dir(s)   4,884,660,224 bytes free
  
  C:\Documents and Settings\Guest\temp>

It seems to me that, if you offer a function to return the filename of a
FILE *, and there /is/ a filename for the file, then you should return the
actual name, and not something concocted by the runtimelibrary as a
standin.

[snip]

-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

Ben Bacarisse said:

<snip>

> [...] 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.)

Alas, that won't work. Consider:

size_t n = strlen(argv[1] + sizeof ".txt";
char *name = malloc(n);
if(name != NULL && sprintf(name, "%s.txt", argv[1]))
{
  FILE *fp = fopen(name, "w");
  free(name);
  if(fp != NULL)
  {
    char *whatever = malloc(n);
    if(whatever != NULL)
    {
      sprintf(whatever, "%s.foo", argv[1]);

Perfectly legal C, but now name no longer points anywhere legal. The second 
call to malloc may well return the same address as the first call (because 
there is an intervening free and the requested size is after all the same 
as before). So a call to _fname or whatever, at this point, would return 
the wrong name.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <g3obin$okn$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:

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

>fname receives a FILE *. not a file descriptor

Does your operating system have no way to get a FILE * other than
fopen() and freopen()?  E.g. functions like unix's popen() and
fdopen()?  If so, presumably you will return NULL for these.

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

In that case it might be better to consistently return a string and
never NULL.  For example, "..unknown.." or "..closed..".

Are filenames starting ".." impossible?  They aren't on other systems,
so if you have an idea that this might be adopted elsewhere you might
want to use something different, though I can't see a nice solution.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

"Nick Keighley" <nick_keighley_nospam@hotmail.com> schreef in bericht 
news:5dbfb650-6dd9-446e-b509-777128c690d0@c58g2000hsc.googlegroups.com...
> On 22 Jun, 02:47, "Serve Lau" <ni...@qinqin.com> wrote:
>> "jacob navia" <ja...@nospam.com> schreef in 
>> berichtnews:g3jucg$d04$1@aioe.org...
>
>> > 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
>
> 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...

It is somewhat:

Environmental limits
The value of FOPEN_MAX shall be at least eight, including the three standard 
text streams.

And in most implementations I've seen FOPEN_MAX is the limit as far as C is 
concerned.
They declare "FILE iob[FOPEN_MAX];" and start returning NULL if you want to 
fopen more. When you do want more you will have to go system specific or 
start different processes.
What better way is there to assure that the standard streams are opened and 
ready. I guess one could do
iob = malloc(FOPEN_MAX * sizeof(*iob));
if (iob == NULL) exit(1);
but nothing is as deterministic on any platform using just FILE 
iob[FOPEN_MAX]

Adding filenames to FILE will make things less deterministic, its 
application programming moved into system libraries without the programmer 
knowing about it. When no memory could be allocated for the filename it will 
store NULL but return a valid pointer in lccwin32. That means that every 
time you call fname() you have to check for NULL and I'm pretty sure people 
will forget that at some point.

On 23 Jun 2008 at 17:23, Richard Tobin wrote:
> In article <g3obin$okn$1@aioe.org>, jacob navia  <jacob@nospam.org> wrote:
>>For stdin stdout and stderr  "..stdin.." "..stdout.." and "..stderr.." 
>>is returned.
>
> In that case it might be better to consistently return a string and
> never NULL.  For example, "..unknown.." or "..closed..".
>
> Are filenames starting ".." impossible?  They aren't on other systems,
> so if you have an idea that this might be adopted elsewhere you might
> want to use something different, though I can't see a nice solution.

Jacob has said that he will return NULL rather than the empty string if
the filename isn't available, so he could adopt the convention that if
_fname(fp) isn't null, and if *_fname(fp) is '\0', then _fname(fp)+1
points to a "special string" like "..stdin.." or whatever. This will be
fine unless you want to port to a system where filenames can contain
'\0' or where filenames can be zero-length.

On Jun 23, 9:22=A0am, jacob navia <ja...@nospam.com> wrote:
> I repeat: fname returns the first argument of fopen.


What's wrong with just calling it _fname?  Then you can do anything
you want.

Richard Heathfield <rjh@see.sig.invalid> writes:

> Ben Bacarisse said:
>
> <snip>
>
>> [...] 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.)
>
> Alas, that won't work. Consider:
>
> size_t n = strlen(argv[1] + sizeof ".txt";
> char *name = malloc(n);
> if(name != NULL && sprintf(name, "%s.txt", argv[1]))
> {
>   FILE *fp = fopen(name, "w");
>   free(name);
>   if(fp != NULL)
>   {
>     char *whatever = malloc(n);
>     if(whatever != NULL)
>     {
>       sprintf(whatever, "%s.foo", argv[1]);
>
> Perfectly legal C, but now name no longer points anywhere legal. The second 
> call to malloc may well return the same address as the first call (because 
> there is an intervening free and the requested size is after all the same 
> as before). So a call to _fname or whatever, at this point, would return 
> the wrong name.

That's a rather convoluted example -- there are lots a cases where the
string used to open file is either no longer there or has been
replaced by something else.  The simplest examples would a buffer that
gets re-used, or a "local" that goes out of scope.

I may have got the wrong end of the stick.  It was my understanding
that the idea was simply for the convenience of the programmer.  The
advantage of the simple pointer copy interface is that just that -- it
is simple to understand and therefore the programmer should know if
the returned result is usable or not.  If they need to track the file
name and choose to use Jacob's extension (with this pointer copy
semantics) then they better make sure the file name sticks around and
remains unmodified.

Reviewing the thread, however, there is some evidence that Jacob wants
the *library* to be able to use the name.  If that is the case then of
course a pointer is no use.  If I'd picked on that hint I'd still have
suggested just copying the pointer, but I'd have added that the
library should not use it!  The benefit to the library of taking a
copy of the name seems too small to be worth the kerfuffle.

-- 
Ben.

In article <slrng602o5.ma2.nospam@nospam.invalid>,
Antoninus Twink  <nospam@nospam.invalid> wrote:

>Jacob has said that he will return NULL rather than the empty string if
>the filename isn't available, so he could adopt the convention that if
>_fname(fp) isn't null, and if *_fname(fp) is '\0', then _fname(fp)+1
>points to a "special string" like "..stdin.." or whatever.

Yes, I almost suggested that.  But it's a bit ugly, isn't it.

>This will be
>fine unless you want to port to a system where filenames can contain
>'\0' or where filenames can be zero-length.

Traditionally on unix systems the empty string refers to the current
directory, and you can, on some systems and some filesystems, fopen()
it.  However, this is such a special case that simply setting the
"special string" to something like "(empty)" would handle it.

-- Richard



-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Richard Bos wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
>> jacob navia wrote:
>>
>>> fopen remembers the file name, and that is what you get
>>
>> 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.

However using the function has made the code impossible to compile
on any other system than Jacobs version of lcc.  This is not an
advisable restriction.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

jacob navia wrote:
> John Bode wrote:
>> jacob navia <ja...@nospam.com> wrote:
>>> Richard wrote:
>>>> CBFalconer <cbfalco...@yahoo.com> writes:
>>>>
.... snip ...
>>>>> 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"?
>>>
>>> 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?
> 
> I repeat: fname returns the first argument of fopen.

So, what possible advantage does this have over saving that name
yourself?

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

In article <48601D24.10D91C6C@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:

>> I repeat: fname returns the first argument of fopen.

>So, what possible advantage does this have over saving that name
>yourself?

You don't have to save it yourself.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

Richard Tobin wrote:
> CBFalconer  <cbfalconer@maineline.net> wrote:
> 
>>> I repeat: fname returns the first argument of fopen.
> 
>> So, what possible advantage does this have over saving that name
>> yourself?
> 
> You don't have to save it yourself.

Exactly.  So now you see the savings in not having fname.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

** Posted from http://www.teranews.com **

Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
> In article <slrng602o5.ma2.nospam@nospam.invalid>,
> Antoninus Twink  <nospam@nospam.invalid> wrote:

> >Jacob has said that he will return NULL rather than the empty string if
> >the filename isn't available, so he could adopt the convention that if
> >_fname(fp) isn't null, and if *_fname(fp) is '\0', then _fname(fp)+1
> >points to a "special string" like "..stdin.." or whatever.

> Yes, I almost suggested that.  But it's a bit ugly, isn't it.

> >This will be
> >fine unless you want to port to a system where filenames can contain
> >'\0' or where filenames can be zero-length.

> Traditionally on unix systems the empty string refers to the current
> directory, and you can, on some systems and some filesystems, fopen()
> it.  However, this is such a special case that simply setting the
> "special string" to something like "(empty)" would handle it.

I'd use special pointers, similar to STDIN_FILENO => 0 relationship. Then
the contents don't have to be magic. The signaling occurs out-of-band, so no
need for special parsing protocols to resolve ambiguity, not to mention the
code would look much cleaner.

jacob navia <jacob@nospam.com> wrote:
> mingyanguo wrote:
> > 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.

> 1) It is not difficult at all to see if the name still matches
>     the contents of the file. Open the file with that name
>     and compare the first bytes... If the data matches with the
>     data in the still opened original file they are the same.
>     That would make you immune against this quite rare problem.

I'll merely assume that you gave no thought to this comment. It happens.

> 2) Under windows it is not possible to erase a file that is
>     already open by another process, as far as I know. If
>     under Unix, you have to take care that when you get the
>     file name you should not assume that the file is still there.
>     All this is not the problem of fopen.

This is an artifact of the filesystem, not the Win32 API specifically. Win32
applications can use non-FAT32 and non-NTFS filesystems, and even run on
non-Microsoft kernels (just in case I'm wrong about where the constraint is
enforced).

Also, newer versions of NTFS support symbolic links, and you can indeed
delete a symbolic link no matter that the target file resource is still
open. And all you'd ever see is the symbolic path. So, ultimately you can
make no guarantees whatsoever. And while I think fname() could be useful,
it's worrisome that you would even entertain such promises.

The Win32 API and the like are already plagued by horrible documentation. In
my short time wading in that pool I'm convinced the vast majority of
programmers rely on superstitution and myth to discern exactly how a
particular interface works, and what it guarantees. It's maddening. Your
comments are archived for perpetuity, and may merely lend credence to some
poor developer's wishful thinking.

> > So, remembering the file name for a FILE rarely makes sense.

> It makes sense in most applications, specially when you write
> a library and you receive a FILE pointer, and you want to
> write a more comprehensible error message than:
>         fprintf(stderr,"Can't write to file %p\n",file);

Honestly, that's only moderately helpful. As a _user_, I couldn't care less
about the name of some obscure application file. I'd rather see something
like, "I'm broken. It's sunny out, go take a walk while an engineer fixes
this issue". (With today's automatic core profilers and phone-home software,
there's no need to gussy up error codes.) As a _programmer_, I'd think twice
about goading an intrepid user into playing around w/ resources which are
meant to be managed by software.

But I realize even moderately can be sufficient reason, though it does go
far in explaining why the interface hasn't made it into many standard APIs.

> There will be no guarantee that the file name is unique, that
> the file name corresponds to a still existing file, etc. It will be
> just the argument you passed to fopen!

Or that the name, even if still valid, points to the actual resource.

Plan9 has a similar interface: fd2path(). The semantics, IIRC, are nearly
identical to what you describe; it is the path passed to open. Except, the
name is the canonical path--as resolved by the kernel--at the time the
resource was acquired. This is unlike, say, Linux's /proc system, where the
kernel endevours to track a valid path to the inode across renames. Neither,
of course, try to dance around the race conditions; both are explicit that
there are no guarantees.

CBFalconer wrote:
> Richard Tobin wrote:
>> CBFalconer  <cbfalconer@maineline.net> wrote:
>>
>>>> I repeat: fname returns the first argument of fopen.
>>> So, what possible advantage does this have over saving that name
>>> yourself?
>> You don't have to save it yourself.
> 
> Exactly.  So now you see the savings in not having fname.
> 
Isn't that the C philosophy: you don't pay for what you don't want?

How often do people want to associate a file name with a FILE object?  I
can't think of a time when I have and I certainly would want either the
time or space overhead on a embedded system.

-- 
Ian Collins.

Ian Collins wrote:
> CBFalconer wrote:
>> Richard Tobin wrote:
>>> CBFalconer  <cbfalconer@maineline.net> wrote:
>>>
>>>>> I repeat: fname returns the first argument of fopen.
>>>> So, what possible advantage does this have over saving that name
>>>> yourself?
>>> You don't have to save it yourself.
>> Exactly.  So now you see the savings in not having fname.
>>
> Isn't that the C philosophy: you don't pay for what you don't want?
> 
> How often do people want to associate a file name with a FILE object?

Every time
	fopen(filename,mode);

A FILE object *is* an association between a name and a disk region.

> I
> can't think of a time when I have and I certainly would want either the
> time or space overhead on a embedded system.

There is no time or overhead involved here. The passed pointer is copied
and that is it. The overhead is minimal compared to all the fields,
buffers and other things fopen must do.

This is a first step in a more general set of functions to get
the properties of a file.

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:
>> CBFalconer wrote:
>>> Richard Tobin wrote:
>>>> CBFalconer  <cbfalconer@maineline.net> wrote:
>>>>
>>>>>> I repeat: fname returns the first argument of fopen.
>>>>> So, what possible advantage does this have over saving that name
>>>>> yourself?
>>>> You don't have to save it yourself.
>>> Exactly.  So now you see the savings in not having fname.
>>>
>> Isn't that the C philosophy: you don't pay for what you don't want?
>>
>> How often do people want to associate a file name with a FILE object?
> 
> Every time
>     fopen(filename,mode);
> 
> A FILE object *is* an association between a name and a disk region.
> 
Quite, the disk region is distinct from one of its possible names.  As
others have said, the name my change or the file may not have a name
after it is opened.

A FILE is a data source and or sink, the name is immaterial.  In most
code I've seen or written, the only place where the name is important is
 the place where the file is opened.

>> I
>> can't think of a time when I have and I certainly would want either the
>> time or space overhead on a embedded system.
> 
> There is no time or overhead involved here. The passed pointer is copied
> and that is it. The overhead is minimal compared to all the fields,
> buffers and other things fopen must do.
> 
A buffer has to be allocated and and the name copied.  True this may
take a trivial time compared with opening a disk file, but not compared
to opening a (FLASH) memory based file.  The extra buffer (be it static
or dynamic) would be an issue on small systems that use files.

I still think the you don't pay for what you don't want manta should
apply here, if you want to pass the name around, encapsulate the FILE
pointer and name in a struct and pass that.

> This is a first step in a more general set of functions to get
> the properties of a file.
> 
Which would be incredibly hard to do given the large number of file
system types with their unique set of properties and characteristics.
You might be interesting in seeing where the C++ world is going with
this, if so check out boost.filesystem.

-- 
Ian Collins.

On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
> CBFalconer wrote:
> > Richard Tobin wrote:
> >> CBFalconer =A0<cbfalco...@maineline.net> wrote:

> >>>> I repeat: fname returns the first argument of fopen.
> >>> So, what possible advantage does this have over saving that name
> >>> yourself?
> >>
> >> You don't have to save it yourself.
>
> > Exactly. =A0So now you see the savings in not having fname.

sorry, no. What is the saving? (I'm not, incidently, in favour
of Jacob's proposal- but I think the criticism should
be rational and clear).


> Isn't that the C philosophy: you don't pay for what you don't want?
>
> How often do people want to associate a file name with a FILE object? =A0

every time there's an error reading a file.

Error: inifile_read.c line 230: parse error reading "BLOB_COUNT"

> I
> can't think of a time when I have and I certainly would want either the
> time or space overhead on a embedded system.

fair point


--
Nick Keighley

"XML is isomorphic to the subset of Lisp data
where the first item in a list is required to be atomic."
          John McCarthy

On 24 Jun, 07:02, jacob navia <ja...@nospam.com> wrote:
> Ian Collins wrote:
> > CBFalconer wrote:
> >> Richard Tobin wrote:
> >>> CBFalconer =A0<cbfalco...@maineline.net> wrote:

> >>>>> I repeat: fname returns the first argument of fopen.
> >>>> So, what possible advantage does this have over saving that name
> >>>> yourself?
> >>>
> >>> You don't have to save it yourself.
> >>
> >> Exactly. =A0So now you see the savings in not having fname.
>
> > Isn't that the C philosophy: you don't pay for what you don't want?
>
> > How often do people want to associate a file name with a FILE object?
>
> Every time
> =A0 =A0 =A0 =A0 fopen(filename,mode);
>
> A FILE object *is* an association between a name and a disk region.

no it isn't This is you fundamental misconception.
Read up on how unix works.



> > I
> > can't think of a time when I have and I certainly would want either the
> > time or space overhead on a embedded system.
>
> There is no time or overhead involved here. The passed pointer is copied
> and that is it.

time and space overhead.


> The overhead is minimal compared to all the fields,
> buffers and other things fopen must do.
>
> This is a first step in a more general set of functions to get
> the properties of a file.

such as? Can you make them platform independant?


--
Nick Keighley

Nick Keighley wrote:
> On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
>> CBFalconer wrote:
>>> Richard Tobin wrote:
>>>> CBFalconer  <cbfalco...@maineline.net> wrote:
> 
>>>>>> I repeat: fname returns the first argument of fopen.
>>>>> So, what possible advantage does this have over saving that name
>>>>> yourself?
>>>> You don't have to save it yourself.
>>> Exactly.  So now you see the savings in not having fname.
> 
> sorry, no. What is the saving? (I'm not, incidently, in favour
> of Jacob's proposal- but I think the criticism should
> be rational and clear).
> 
> 
>> Isn't that the C philosophy: you don't pay for what you don't want?
>>
>> How often do people want to associate a file name with a FILE object?  
> 
> every time there's an error reading a file.
> 
The name is know at the point where the file is opened, otherwise it
would be a little difficult opening it...

-- 
Ian Collins.

On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.com> wrote:
> Nick Keighleywrote:
> > On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
> >> CBFalconer wrote:
> >>> Richard Tobin wrote:
> >>>> CBFalconer =A0<cbfalco...@maineline.net> wrote:

> >>>>>> I repeat: fname returns the first argument of fopen.
> >>>>> So, what possible advantage does this have over saving that name
> >>>>> yourself?
> >>>> You don't have to save it yourself.
> >>> Exactly. =A0So now you see the savings in not having fname.
>
> > sorry, no. What is the saving? (I'm not, incidently, in favour
> > of Jacob's proposal- but I think the criticism should
> > be rational and clear).
>
> >> Isn't that the C philosophy: you don't pay for what you don't want?
>
> >> How often do people want to associate a file name with a FILE object? =
=A0
>
> > every time there's an error reading a file.
>
> The name is know at the point where the file is opened, otherwise it
> would be a little difficult opening it...

I said *reading* not opening. And you snipped the example


--
Nick Keighley

Nick Keighley wrote:
> On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.com> wrote:
>> Nick Keighleywrote:
>>> On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> CBFalconer wrote:
>>>>> Richard Tobin wrote:
>>>>>> CBFalconer  <cbfalco...@maineline.net> wrote:
> 
>>>>>>>> I repeat: fname returns the first argument of fopen.
>>>>>>> So, what possible advantage does this have over saving that name
>>>>>>> yourself?
>>>>>> You don't have to save it yourself.
>>>>> Exactly.  So now you see the savings in not having fname.
>>> sorry, no. What is the saving? (I'm not, incidently, in favour
>>> of Jacob's proposal- but I think the criticism should
>>> be rational and clear).
>>>> Isn't that the C philosophy: you don't pay for what you don't want?
>>>> How often do people want to associate a file name with a FILE object?  
>>> every time there's an error reading a file.
>> The name is know at the point where the file is opened, otherwise it
>> would be a little difficult opening it...
> 
> I said *reading* not opening. And you snipped the example
> 
Oops..

-- 
Ian Collins.

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.com> wrote:
>> Nick Keighleywrote:
>> > On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
>> >> CBFalconer wrote:
>> >>> Richard Tobin wrote:
>> >>>> CBFalconer  <cbfalco...@maineline.net> wrote:
>
>> >>>>>> I repeat: fname returns the first argument of fopen.
>> >>>>> So, what possible advantage does this have over saving that name
>> >>>>> yourself?
>> >>>> You don't have to save it yourself.
>> >>> Exactly.  So now you see the savings in not having fname.
>>
>> > sorry, no. What is the saving? (I'm not, incidently, in favour
>> > of Jacob's proposal- but I think the criticism should
>> > be rational and clear).
>>
>> >> Isn't that the C philosophy: you don't pay for what you don't want?
>>
>> >> How often do people want to associate a file name with a FILE object?  
>>
>> > every time there's an error reading a file.
>>
>> The name is know at the point where the file is opened, otherwise it
>> would be a little difficult opening it...
>
> I said *reading* not opening. And you snipped the example

It's called "memory Nick". Try "remembering" the name in a "variable" or
similar. It's complicated but good.

On 24 Jun, 10:03, Richard<rgr...@gmail.com> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.com> wrote:
> >> Nick Keighleywrote:
> >> > On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
> >> >> CBFalconer wrote:
> >> >>> Richard Tobin wrote:
> >> >>>> CBFalconer =A0<cbfalco...@maineline.net> wrote:

> >> >>>>>> I repeat: fname returns the first argument of fopen.
> >> >>>>> So, what possible advantage does this have over saving that name
> >> >>>>> yourself?
> >> >>>> You don't have to save it yourself.
> >> >>> Exactly. =A0So now you see the savings in not having fname.
>
> >> > sorry, no. What is the saving? (I'm not, incidently, in favour
> >> > of Jacob's proposal- but I think the criticism should
> >> > be rational and clear).
>
> >> >> Isn't that the C philosophy: you don't pay for what you don't want?
>
> >> >> How often do people want to associate a file name with a FILE objec=
t? =A0
>
> >> > every time there's an error reading a file.
>
> >> The name is know at the point where the file is opened, otherwise it
> >> would be a little difficult opening it...
>
> > I said *reading* not opening. And you snipped the example
>
> It's called "memory Nick". Try "remembering" the name in a "variable" or
> similar. It's complicated but good

que?

I was argueing there *was* reason for sometimes requiring the filename
after the fopen(). So, yes, I store it in a variable. Your point?


--
Nick Keighley

What goes "Pieces of Seven! Pieces of Seven!"?
A Parroty Error.

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:6cblpmF3f6t0sU2@mid.individual.net...
> jacob navia wrote:

>> A FILE object *is* an association between a name and a disk region.
>>
> Quite, the disk region is distinct from one of its possible names.  As
> others have said, the name my change or the file may not have a name
> after it is opened.
>
> A FILE is a data source and or sink, the name is immaterial.

The name is important enough for the OS to store it with each file. All 
those dir/ls listings would be really confusing if all you saw was block 
numbers.

Now, there may be OS's striving hard to avoid the 1:1 correspondence between 
disk region and filename that would otherwise make things far too simple for 
programmers. But this /is/ for Windows.

> In most
> code I've seen or written, the only place where the name is important is
> the place where the file is opened.

The name is important to the end-user, if it's a file he cares about (or, if 
it goes wrong, even if he doesn't).

> A buffer has to be allocated and and the name copied.  True this may
> take a trivial time compared with opening a disk file, but not compared
> to opening a (FLASH) memory based file.

If flash memory is slower, the name-handling overhead would be even more 
trivial.

-- 
Bartc 

jacob navia said:

> Ian Collins wrote:

<snip>

>> I
>> can't think of a time when I have and I certainly would want either the
>> time or space overhead on a embedded system.
> 
> There is no time or overhead involved here.

You can't make a copy in zero time or zero space, except if there is 
nothing to copy (in which case it isn't much use, is it?).

> The passed pointer is copied and that is it.

Little overhead != no overhead.

> The overhead is minimal compared to all the fields,
> buffers and other things fopen must do.

Yes. So are all such overheads. But they add up. The nice thing about C is 
that you pay for what you ask for, and nothing else. The fopen function 
just opens the file, and that's all. No hidden overheads - *at all*.

> This is a first step in a more general set of functions to get
> the properties of a file.

Right - the overhead starts off small, and then over time it grows, and 
eventually it's actually so big that it's slowing me down way too much, 
but it's too late to do anything about it because the source code is 
chock-full of all these extensions that stop me porting to a leaner 
compiler. Far easier just to say "no" right at the beginning.

If you must introduce such features, I suggest you also provide a way of 
turning them off.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <Uh38k.14746$E41.13810@text.news.virginmedia.com>,
Bartc <bc@freeuk.com> wrote:
>"Ian Collins" <ian-news@hotmail.com> wrote in message 
>news:6cblpmF3f6t0sU2@mid.individual.net...

>> A FILE is a data source and or sink, the name is immaterial.

>The name is important enough for the OS to store it with each file. All 
>those dir/ls listings would be really confusing if all you saw was block 
>numbers.

I don't recall that I have encountered even a single Unix filesystem that
stored the file name with each file: each of them that I have
seen has segregated the name from the information about the file
(ownership, size, location of information on the disk), and most of them
have allowed multiple names to relate to the same file.

>Now, there may be OS's striving hard to avoid the 1:1 correspondence between 
>disk region and filename that would otherwise make things far too simple for 
>programmers. But this /is/ for Windows.

But you said "dir/ls listings". Did Windows adopt "ls" as a command
somewhere along the way? And did the NTFS filesystem lose 
"directory junctions", "hard links", and "single instance storage" ?
-- 
  "A scientist who cannot prove what he has accomplished,
  has accomplished nothing."                  -- Walter Reisch

In article <aPCdnUlvCde3Xf3VnZ2dnUVZ8hidnZ2d@bt.com>,
Richard Heathfield  <rjh@see.sig.invalid> wrote:

>The nice thing about C is 
>that you pay for what you ask for, and nothing else. The fopen function 
>just opens the file, and that's all. No hidden overheads - *at all*.

That would depend very much on what you consider to be an "overhead".
For example on any POSIX system, it is required that the file
access-time be updated when the file is opened (unless the filesystem
is read-only). Access-time and last-changed-time and the like
wre unwanted / unnessary overheads in some situations.

True this is a POSIX behaviour rather than a C fopen() mandated
behaviour, but I believe it still is enough to establish
a counter argument to the "at all" part of "No hidden overheads - *at all*"
-- 
amazon.com's top 8 books about "walter" are Kotzwinkle/ Gundy/ Colman's
"Walter the Farting Dog"

Walter Roberson said:

> In article <aPCdnUlvCde3Xf3VnZ2dnUVZ8hidnZ2d@bt.com>,
> Richard Heathfield  <rjh@see.sig.invalid> wrote:
> 
>>The nice thing about C is
>>that you pay for what you ask for, and nothing else. The fopen function
>>just opens the file, and that's all. No hidden overheads - *at all*.
> 
> That would depend very much on what you consider to be an "overhead".
> For example on any POSIX system, it is required that the file
> access-time be updated when the file is opened (unless the filesystem
> is read-only). Access-time and last-changed-time and the like
> wre unwanted / unnessary overheads in some situations.
> 
> True this is a POSIX behaviour rather than a C fopen() mandated
> behaviour, but I believe it still is enough to establish
> a counter argument to the "at all" part of "No hidden overheads - *at
> all*"

Yes, I should have restricted my claim to overheads introduced by the 
implementation. Obviously it, and the program, have to play nice with the 
system, and obviously there's an overhead involved in so doing.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Walter Roberson wrote:
> 
.... snip ...
> 
> But you said "dir/ls listings".  Did Windows adopt "ls" as a
> command somewhere along the way?  And did the NTFS filesystem lose
> "directory junctions", "hard links", and "single instance storage"?

All you have to do is mount the DJGPP system ls command.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

Keith Thompson wrote:
> jacob navia <jacob@nospam.com> writes:
> > 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 *);
>
> I mildly prefer "fname".  I strongly suggest that it *not* be
> declared in <stdio.h>, even in non-conforming mode.

Obviously it shouldn't be declared in conforming mode, but
clearly the function is synonymous with <stdio.h>.

> > What problems could arise with this function?
>
> It assumes that each stream is associated with exactly one
> file name.

No, it assumes you pass exactly one file name to fopen() [or
freopen().]
That's not unreasonable!

> Depending on the system, some streams are not
> associated with any named file,

By default (until freopen say) I return "stdin" for stdin, etc...

> and some many have multiple equally valid names.

But that's not what FileName is capturing.

> There are a number of decisions you'd have to make *and
> document* about the form of the name.

So 7.19.3p8 says, but I don't see why that's important to fname()
which simply returns what was passed to fopen(). [Or something
like it; truncated to FILENAME_MAX-1 characters in my case.]

> For Windows, you've already specified
> lower case, which isn't necessarily ideal.

I think Jacob was simply referring to the lower case of the
function name "fname". FNAME() would look out of place
against fopen, fwrite etc...

> Other possibilities are the name used to open it, ...

That's what he's proposing.

> Does the Windows API already provide something like this?

The point is that <stdio.h> doesn't.

In my own case, rather than modify the C library, I have an
alternate header that wraps over <stdio.h> to provider a
filename and other things. The filename part is certainly
implementable in pure ISO C.

I'm pretty sure if it was available in C89, it would be in
significant use. Although I can understand why it wasn't
standardised.

--
Peter

Peter Nilsson wrote:
> Keith Thompson wrote:
>> jacob navia <jacob@nospam.com> writes:
>>
>>> 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
>>
.... snip ...
> 
> That's what he's proposing.
> 
>> Does the Windows API already provide something like this?
> 
> The point is that <stdio.h> doesn't.
> 
.... snip ...
> 
> I'm pretty sure if it was available in C89, it would be in
> significant use. Although I can understand why it wasn't
> standardised.

Very simple.  It is IMPOSSIBLE to provide in general, and
particularly on the heart systems using C, i.e. Linux/Unix/Posix. 
Files on these systems have no particular name, and the name to a
user is assigned by a link to the file, kept in some directory. 
The number of links, and names, is unlimited.

If you just want the name under which the file was opened, save
that at fopen time.  No load on the library, no muss, no fuss.  See
the strcpy function.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

CBFalconer <cbfalconer@yahoo.com> writes:

> Peter Nilsson wrote:
<snip>

And I am safe in snipping most of the stuff that you left because you
had already removed all of the text form Peter Nilsson that explained
away your objections.  Of course, that makes this reply of mine
unintelligible by your rules, but you did the cutting, not me.

>> I'm pretty sure if it was available in C89, it would be in
>> significant use. Although I can understand why it wasn't
>> standardised.
>
> Very simple.

Yes, he explained a simple-to-implement semantics for the function in
question but I doubt you intended to agree with him.  Did you
miss-read the last sentence as "I *can't* understand why is wasn't
standardised"?

>  It is IMPOSSIBLE to provide in general, and
> particularly on the heart systems using C, i.e. Linux/Unix/Posix. 
> Files on these systems have no particular name, and the name to a
> user is assigned by a link to the file, kept in some directory. 
> The number of links, and names, is unlimited.

Please lets not go round this again.  You cut from your reply all the
parts where Peter explained how simple it would be.  That fact that
one can't implement the semantics that *you* think the mechanism
should have is neither here nor there.  Of course, you could object
to the semantics that Peter was suggesting, but you did not do that
either.

The real objection to this idea is that will draw people in to using a
non-standard extension.  Also, if copying is involved, that it imposes
a penalty, though it would be simple to turn it all off (including any
overhead) if compiling in standards mode.

-- 
Ben.

CBFalconer wrote:
> If you just want the name under which the file was opened, save
> that at fopen time.  No load on the library, no muss, no fuss.  See
> the strcpy function.
> 

Yes sure. And how do the other functions that need this information
will be able to get it????

Suppose

int readfromLog(FILE *fp)
{
	char buf[512];
	size_t bufsiz=sizeof(buf);
	int s = fread(buf,1,bufsiz,fp);
	if (s <= 0) {
		// How do I get the name of the file here Mr Falconer?
	}
}

You see the problem?

Now ALL the interfaces to ALL the functions that could need this
information (or that call a function that could need this
information) need their interface CHANGED to have ONE EXTRA PARAMETER!

This is completely impossible to do in complex systems!

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Ben Bacarisse wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
>> Peter Nilsson wrote:
>
.... snip ...
> 
>>> I'm pretty sure if it was available in C89, it would be in
>>> significant use. Although I can understand why it wasn't
>>> standardised.
>>
>> Very simple.
> 
> Yes, he explained a simple-to-implement semantics for the function
> in question but I doubt you intended to agree with him.  Did you
> miss-read the last sentence as "I *can't* understand why is wasn't
> standardised"?

Yes, I so misread it.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

** Posted from http://www.teranews.com **

CBFalconer wrote:

> Peter Nilsson wrote:
>> Keith Thompson wrote:
>>> jacob navia <jacob@nospam.com> writes:
>>>
>>>> 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
>>>
> ... snip ...
>> 
>> That's what he's proposing.
>> 
>>> Does the Windows API already provide something like this?
>> 
>> The point is that <stdio.h> doesn't.
>> 
> ... snip ...
>> 
>> I'm pretty sure if it was available in C89, it would be in
>> significant use. Although I can understand why it wasn't
>> standardised.
> 
> Very simple.  It is IMPOSSIBLE to provide in general, and
> particularly on the heart systems using C, i.e. Linux/Unix/Posix. 
> Files on these systems have no particular name, and the name to a
> user is assigned by a link to the file, kept in some directory. 
> The number of links, and names, is unlimited.
> 
> If you just want the name under which the file was opened, save
> that at fopen time.  

That doesn't help ONE LITTLE BIT if some OTHER piece of code
NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
somewhere. In that case everyone's RANTING that YOU CAN DO IT
YOURSELF is revealed as a FINE CASE OF missing the POINT; 
you /can't/ do it yourself, because in general you can't
refactor all the code.

-- 
"Only he had not reckoned with the ways of Estcarp."              /Witch World/

Hewlett-Packard Limited registered office:                Cain Road, Bracknell,
registered no: 690597 England                                    Berks RG12 1HN

On Jun 25, 5:55 pm, jacob navia <ja...@nospam.com> wrote:
> CBFalconer wrote:
> > If you just want the name under which the file was opened, save
> > that at fopen time.  No load on the library, no muss, no fuss.  See
> > the strcpy function.
>
> Yes sure. And how do the other functions that need this information
> will be able to get it????
>
> Suppose
>
> int readfromLog(FILE *fp)
> {
>         char buf[512];
>         size_t bufsiz=sizeof(buf);
>         int s = fread(buf,1,bufsiz,fp);
fread returns size_t, not int.
>         if (s <= 0) {
This 'if' is not meaningful
>                 // How do I get the name of the file here Mr Falconer?
>         }
>
> }
>
> You see the problem?
With the current design of readfromLog? I see three problems!

> Now ALL the interfaces to ALL the functions that could need this
> information (or that call a function that could need this
> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
>
> This is completely impossible to do in complex systems!
No it's not.
You'd simply design readfromLog differently:

int readfromLog(MYFILE *fp)
{
/* ... */
if(s <= 0) {
    fp->name ...


Come on Mr Navia, do you honestly believe that this is a serious/hard
issue to solve for a complex system programmer?

jacob navia <jacob@nospam.com> writes:

> CBFalconer wrote:
>> If you just want the name under which the file was opened, save
>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> the strcpy function.
>
> Yes sure. And how do the other functions that need this information
> will be able to get it????

I am sure you know the answer to that.

> Suppose
>
> int readfromLog(FILE *fp)
> {
> 	char buf[512];
> 	size_t bufsiz=sizeof(buf);
> 	int s = fread(buf,1,bufsiz,fp);
> 	if (s <= 0) {
> 		// How do I get the name of the file here Mr Falconer?
> 	}
> }
>
> You see the problem?

I think most people here understand the problem and your intent.  The
problem is that those of us who have solved it have done so already in
a portable way and your solution will tie people in to one
implementation.

> Now ALL the interfaces to ALL the functions that could need this
> information (or that call a function that could need this
> information) need their interface CHANGED to have ONE EXTRA
> PARAMETER!

Not necessarily.  The most common solution is to wrap a FILE * in a
struct that has the extra data.  In several programs of mine, the name
is not enough -- I need line number information as well -- so your
solution is only a partial one for that use case.

> This is completely impossible to do in complex systems!

That is over-stating the case.  It is not impossible.  If you know of
anyone who believes this and has money to spare, let me know.

-- 
Ben.

On Jun 25, 6:07 pm, Chris Dollin <chris.dol...@hp.com> wrote:
> CBFalconer wrote:
> > Peter Nilsson wrote:
> >> Keith Thompson wrote:
> >>> jacob navia <ja...@nospam.com> writes:
>
> >>>> 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
>
> > ... snip ...
>
> >> That's what he's proposing.
>
> >>> Does the Windows API already provide something like this?
>
> >> The point is that <stdio.h> doesn't.
>
> > ... snip ...
>
> >> I'm pretty sure if it was available in C89, it would be in
> >> significant use. Although I can understand why it wasn't
> >> standardised.
>
> > Very simple.  It is IMPOSSIBLE to provide in general, and
> > particularly on the heart systems using C, i.e. Linux/Unix/Posix.
> > Files on these systems have no particular name, and the name to a
> > user is assigned by a link to the file, kept in some directory.
> > The number of links, and names, is unlimited.
>
> > If you just want the name under which the file was opened, save
> > that at fopen time.
>
> That doesn't help ONE LITTLE BIT if some OTHER piece of code
> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
> somewhere. In that case everyone's RANTING that YOU CAN DO IT
> YOURSELF is revealed as a FINE CASE OF missing the POINT;
> you /can't/ do it yourself, because in general you can't
> refactor all the code.
In that case you expect that OTHER piece of code to also save the
filename, IF it is ever going to be needed.
If it is indeed going to be needed but the OTHER piece of code does
not save it, then it's most likely bad code.
When I use code from someone else, a library for example, I expect him
to have thought out all the design issues.
If he has not done so, I can either e-mail him about it, contribute
code, use it as is, or move on to the next library.
I /won't/ expect my compiler to have feature X to save me.

Ben Bacarisse wrote:
> jacob navia <jacob@nospam.com> writes:

> Not necessarily.  The most common solution is to wrap a FILE * in a
> struct that has the extra data.  In several programs of mine, the name

>> This is completely impossible to do in complex systems!
>
> That is over-stating the case.  It is not impossible.  If you know of
> anyone who believes this and has money to spare, let me know.

If you're distributing a library of some kind (it could be dynamic or 
static), and want to update one of the functions so that it can make use of 
the filename of a file-handle, then your solution would involve all the 
thousands of users of your library in updating their code.

By building in the new capability to FILE, only relinking is needed; you can 
leave millions of lines of code untouched. So it's not impossible, but may 
not be practical.

If the file functions are in a dynamic library anyway, possibly not even 
that is needed, and the new functionality doesn't even need a programmer, 
just a download of a library.

-- 
Bartc 

vippstar@gmail.com wrote:
> On Jun 25, 5:55 pm, jacob navia <ja...@nospam.com> wrote:
>> CBFalconer wrote:
>>> If you just want the name under which the file was opened, save
>>> that at fopen time.  No load on the library, no muss, no fuss.  See
>>> the strcpy function.
>> Yes sure. And how do the other functions that need this information
>> will be able to get it????
>>
>> Suppose
>>
>> int readfromLog(FILE *fp)
>> {
>>         char buf[512];
>>         size_t bufsiz=sizeof(buf);
>>         int s = fread(buf,1,bufsiz,fp);
> fread returns size_t, not int.
>>         if (s <= 0) {
> This 'if' is not meaningful
>>                 // How do I get the name of the file here Mr Falconer?
>>         }
>>
>> }
>>
>> You see the problem?
> With the current design of readfromLog? I see three problems!
> 
>> Now ALL the interfaces to ALL the functions that could need this
>> information (or that call a function that could need this
>> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
>>
>> This is completely impossible to do in complex systems!
> No it's not.
> You'd simply design readfromLog differently:
> 
> int readfromLog(MYFILE *fp)
> {
> /* ... */
> if(s <= 0) {
>     fp->name ...
> 
> 
> Come on Mr Navia, do you honestly believe that this is a serious/hard
> issue to solve for a complex system programmer?

Nothing of course. Nothing.

A good systems programmer will
1) Change all calls that use FILE to use MYFILE

Then, change all calls to fread/fwrite to
fread (... fp->file);
and NOT
fread(..., fp);

THEN

determine which libraries need a FILE * and change all calls to
libraries to get fp->file instead of fp

Obviously yours is a very simple solution that can be done
in a minute. My solution, that needs

	name = _fname(fp);

is much too complicated and needs too much work/effort.



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Jun 25, 7:51 pm, jacob navia <ja...@nospam.com> wrote:
> vipps...@gmail.com wrote:
> > On Jun 25, 5:55 pm, jacob navia <ja...@nospam.com> wrote:
> >> CBFalconer wrote:
> >>> If you just want the name under which the file was opened, save
> >>> that at fopen time.  No load on the library, no muss, no fuss.  See
> >>> the strcpy function.
> >> Yes sure. And how do the other functions that need this information
> >> will be able to get it????
>
> >> Suppose
>
> >> int readfromLog(FILE *fp)
> >> {
> >>         char buf[512];
> >>         size_t bufsiz=sizeof(buf);
> >>         int s = fread(buf,1,bufsiz,fp);
> > fread returns size_t, not int.
> >>         if (s <= 0) {
> > This 'if' is not meaningful
> >>                 // How do I get the name of the file here Mr Falconer?
> >>         }
>
> >> }
>
> >> You see the problem?
> > With the current design of readfromLog? I see three problems!
>
> >> Now ALL the interfaces to ALL the functions that could need this
> >> information (or that call a function that could need this
> >> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
>
> >> This is completely impossible to do in complex systems!
> > No it's not.
> > You'd simply design readfromLog differently:
>
> > int readfromLog(MYFILE *fp)
> > {
> > /* ... */
> > if(s <= 0) {
> >     fp->name ...
>
> > Come on Mr Navia, do you honestly believe that this is a serious/hard
> > issue to solve for a complex system programmer?
>
> Nothing of course. Nothing.
>
> A good systems programmer will
> 1) Change all calls that use FILE to use MYFILE
>
> Then, change all calls to fread/fwrite to
> fread (... fp->file);
> and NOT
> fread(..., fp);
>
> THEN
>
> determine which libraries need a FILE * and change all calls to
> libraries to get fp->file instead of fp
>
> Obviously yours is a very simple solution that can be done
> in a minute. My solution, that needs
>
>         name = _fname(fp);
>
> is much too complicated and needs too much work/effort.

So you are adding features to your compiler to save your users some
typing?
Why don't you write a text editor instead of a compiler Mr Navia?

vippstar@gmail.com writes:

> On Jun 25, 7:51 pm, jacob navia <ja...@nospam.com> wrote:
>> vipps...@gmail.com wrote:
>> > On Jun 25, 5:55 pm, jacob navia <ja...@nospam.com> wrote:
>> >> CBFalconer wrote:
>> >>> If you just want the name under which the file was opened, save
>> >>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> >>> the strcpy function.
>> >> Yes sure. And how do the other functions that need this information
>> >> will be able to get it????
>>
>> >> Suppose
>>
>> >> int readfromLog(FILE *fp)
>> >> {
>> >>         char buf[512];
>> >>         size_t bufsiz=sizeof(buf);
>> >>         int s = fread(buf,1,bufsiz,fp);
>> > fread returns size_t, not int.
>> >>         if (s <= 0) {
>> > This 'if' is not meaningful
>> >>                 // How do I get the name of the file here Mr Falconer?
>> >>         }
>>
>> >> }
>>
>> >> You see the problem?
>> > With the current design of readfromLog? I see three problems!
>>
>> >> Now ALL the interfaces to ALL the functions that could need this
>> >> information (or that call a function that could need this
>> >> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
>>
>> >> This is completely impossible to do in complex systems!
>> > No it's not.
>> > You'd simply design readfromLog differently:
>>
>> > int readfromLog(MYFILE *fp)
>> > {
>> > /* ... */
>> > if(s <= 0) {
>> >     fp->name ...
>>
>> > Come on Mr Navia, do you honestly believe that this is a serious/hard
>> > issue to solve for a complex system programmer?
>>
>> Nothing of course. Nothing.
>>
>> A good systems programmer will
>> 1) Change all calls that use FILE to use MYFILE
>>
>> Then, change all calls to fread/fwrite to
>> fread (... fp->file);
>> and NOT
>> fread(..., fp);
>>
>> THEN
>>
>> determine which libraries need a FILE * and change all calls to
>> libraries to get fp->file instead of fp
>>
>> Obviously yours is a very simple solution that can be done
>> in a minute. My solution, that needs
>>
>>         name = _fname(fp);
>>
>> is much too complicated and needs too much work/effort.
>
> So you are adding features to your compiler to save your users some
> typing?

"indeed"

> Why don't you write a text editor instead of a compiler Mr Navia?

If he does, maybe you could use it? The layout of your replies is
awful. You leave no white space after the quoted material and then put
gratuitous breaks everywhere.

But I'm interested in whose sock puppet you are. You seem to delight in
prancing around putting people down. Not quite as much as your master,
but pretty revolting behaviour nonetheless "Mr" Vippstar.

jacob navia escreveu:
> CBFalconer wrote:
>> If you just want the name under which the file was opened, save
>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> the strcpy function.
>>
> 
> Yes sure. And how do the other functions that need this information
> will be able to get it????
> 
> Suppose
> 
> int readfromLog(FILE *fp)
> {
>     char buf[512];
>     size_t bufsiz=sizeof(buf);
>     int s = fread(buf,1,bufsiz,fp);
>     if (s <= 0) {
>         // How do I get the name of the file here Mr Falconer?
>     }
> }
> 
> You see the problem?

Also to comment Chris Dollin's remark. The idiomatic way of doing this 
is not to write the name of the file in the body of 'if' but instead 
construct the readfromLog() interface in a way it returns error codes 
which are processed by the caller.

Also, the function [_]fname as proposed would have serious problems if 
you attempt to use it in a POSIX environment where FILE *fmemopen() or 
FILE *open_memstream() are expected to exist and they have no name 
assosiated with.

My humble suggestion is you either use for Windows the already suggested 
API as the effort to have a full functioning [_]fname() is all platforms 
would not be worth of it.

My .0199999....

--
Cesar Rabak

"Chris Dollin" <chris.dollin@hp.com> schreef in bericht 
news:g3tmvu$q14$1@news-pa1.hpl.hp.com...
> CBFalconer wrote:
>
>> Peter Nilsson wrote:
>>> Keith Thompson wrote:
>>>> jacob navia <jacob@nospam.com> writes:
>>>>
>>>>> 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
>>>>
>> ... snip ...
>>>
>>> That's what he's proposing.
>>>
>>>> Does the Windows API already provide something like this?
>>>
>>> The point is that <stdio.h> doesn't.
>>>
>> ... snip ...
>>>
>>> I'm pretty sure if it was available in C89, it would be in
>>> significant use. Although I can understand why it wasn't
>>> standardised.
>>
>> Very simple.  It is IMPOSSIBLE to provide in general, and
>> particularly on the heart systems using C, i.e. Linux/Unix/Posix.
>> Files on these systems have no particular name, and the name to a
>> user is assigned by a link to the file, kept in some directory.
>> The number of links, and names, is unlimited.
>>
>> If you just want the name under which the file was opened, save
>> that at fopen time.
>
> That doesn't help ONE LITTLE BIT if some OTHER piece of code
> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
> somewhere. In that case everyone's RANTING that YOU CAN DO IT
> YOURSELF is revealed as a FINE CASE OF missing the POINT;
> you /can't/ do it yourself, because in general you can't
> refactor all the code.

that only works if that code is also written with lcc....

// function using MSVC runtime you have no control over
FILE *openfile(const char *file);

// function used in lcc
FILE *fp = openfile("test");
if (fp != NULL)
{
  printf("%s\n", fname(fp));
}

How stable is this code??? it compiles fine with no warnings.

Or did you mean with code you have no control over that the one who 
maintains the software containing openfile is working in the same company? 
You have learnt to talk. If you are too afraid to ask them to change it you 
can still do it yourself.

MYFILE f;
f.name = "test.txt";
f.fp = openfile(f.name);

that wasnt so hard to do even when you dont have control over openfile

Serve Lau said:

> 
> "Chris Dollin" <chris.dollin@hp.com> schreef in bericht
> news:g3tmvu$q14$1@news-pa1.hpl.hp.com...
>> CBFalconer wrote:
>>
<snip>
>>>
>>> If you just want the name under which the file was opened, save
>>> that at fopen time.
>>
>> That doesn't help ONE LITTLE BIT if some OTHER piece of code
>> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
>> somewhere. In that case everyone's RANTING that YOU CAN DO IT
>> YOURSELF is revealed as a FINE CASE OF missing the POINT;
>> you /can't/ do it yourself, because in general you can't
>> refactor all the code.
> 
<snip>
> 
> Or did you mean with code you have no control over that the one who
> maintains the software containing openfile is working in the same
> company? You have learnt to talk.

That won't help if you don't have the authority to request a change, or if 
the library writer has gone out of business leaving you with a legacy lib 
and no budget to rewrite it.

> If you are too afraid to ask them to
> change it you can still do it yourself.

Not if you're being paid to do other stuff.

> MYFILE f;
> f.name = "test.txt";
> f.fp = openfile(f.name);
> 
> that wasnt so hard to do even when you dont have control over openfile

Strawman. Now consider a library written by someone else, one that provides 
you with a file pointer but where you don't get to provide the filename. 
Consider, for example:

FILE *open_config_file(int subprogramID);

where the decision about which config file to open is taken from you.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Cesar Rabak wrote:
> jacob navia escreveu:
>> CBFalconer wrote:
>>> If you just want the name under which the file was opened, save
>>> that at fopen time.  No load on the library, no muss, no fuss.  See
>>> the strcpy function.
>>>
>>
>> Yes sure. And how do the other functions that need this information
>> will be able to get it????
>>
>> Suppose
>>
>> int readfromLog(FILE *fp)
>> {
>>     char buf[512];
>>     size_t bufsiz=sizeof(buf);
>>     int s = fread(buf,1,bufsiz,fp);
>>     if (s <= 0) {
>>         // How do I get the name of the file here Mr Falconer?
>>     }
>> }
>>
>> You see the problem?
> 
> Also to comment Chris Dollin's remark. The idiomatic way of doing this 
> is not to write the name of the file in the body of 'if' but instead 
> construct the readfromLog() interface in a way it returns error codes 
> which are processed by the caller.
> 

Then the same problem will appear in the caller. You will have to keep 
that information in a associative list (or in a structure containing the
file) , then modify a lot of interfaces to pass an extra parameter or
a different structure than FILE *.

This is not possible when you are writing a library (and can't ask the
user to pass you the file name because the user may not know it, or
did not store it, etc)

This is a discussion where the principle of keeping related information
in one place holds. The best place to keep the file name information is
in the fopen function since it is that function the constructor of
the FILE structure. Any other solution means a replication of effort
that should be done when constructing the object.

> Also, the function [_]fname as proposed would have serious problems if 
> you attempt to use it in a POSIX environment where FILE *fmemopen() or 
> FILE *open_memstream() are expected to exist and they have no name 
> assosiated with.
> 

How many times must I repeat the same thing? If there is no file name
you can always return NULL (meaning there is no file name) or some
made up name like "/\/\stdin/\/\"...


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> vippstar@gmail.com wrote:

>> No it's not.
>> You'd simply design readfromLog differently:
>>
>> int readfromLog(MYFILE *fp)
>> {
>> /* ... */
>> if(s <= 0) {
>>     fp->name ...
>>
>>
>> Come on Mr Navia, do you honestly believe that this is a serious/hard
>> issue to solve for a complex system programmer?
> 
> Nothing of course. Nothing.
> 
> A good systems programmer will
> 1) Change all calls that use FILE to use MYFILE
> 
> Then, change all calls to fread/fwrite to
> fread (... fp->file);
> and NOT
> fread(..., fp);
> 
> THEN
> 
> determine which libraries need a FILE * and change all calls to
> libraries to get fp->file instead of fp
> 
> Obviously yours is a very simple solution that can be done
> in a minute. My solution, that needs
> 
>     name = _fname(fp);
> 
> is much too complicated and needs too much work/effort.
> 
Find a decent refactoring editor, or use a platform with decent command
line tools to do the same job.

-- 
Ian Collins.

"jacob navia" <jacob@nospam.com> ha scritto nel messaggio
news:g3tm8c$asj$1@aioe.org...
> CBFalconer wrote:
>> If you just want the name under which the file was opened, save
>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> the strcpy function.
>>
>
> Yes sure. And how do the other functions that need this information
> will be able to get it????
>
> Suppose
>
> int readfromLog(FILE *fp)
> {
> char buf[512];
> size_t bufsiz=sizeof(buf);
> int s = fread(buf,1,bufsiz,fp);
> if (s <= 0) {
> // How do I get the name of the file here Mr Falconer?
> }
> }


> You see the problem?

where is?

int readfromLog(FILE*  fp, int*  p)
{
  char buf[512];
  size_t bufsiz=sizeof(buf); *p=0;
  int s = fread(buf,1,bufsiz,fp);
  *p=s
  if (s <= 0) return  1;
.....
 }


> Now ALL the interfaces to ALL the functions that could need this
> information (or that call a function that could need this
> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
>
> This is completely impossible to do in complex systems!

why "ONE EXTRA PARAMETER" is not good?

>
> -- 
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatique
> http://www.cs.virginia.edu/~lcc-win32

jacob navia escreveu:
> Cesar Rabak wrote:
>> jacob navia escreveu:
>>> CBFalconer wrote:
>>>> If you just want the name under which the file was opened, save
>>>> that at fopen time.  No load on the library, no muss, no fuss.  See
>>>> the strcpy function.
>>>>
>>>
>>> Yes sure. And how do the other functions that need this information
>>> will be able to get it????
>>>
>>> Suppose
>>>
>>> int readfromLog(FILE *fp)
>>> {
>>>     char buf[512];
>>>     size_t bufsiz=sizeof(buf);
>>>     int s = fread(buf,1,bufsiz,fp);
>>>     if (s <= 0) {
>>>         // How do I get the name of the file here Mr Falconer?
>>>     }
>>> }
>>>
>>> You see the problem?
>>
>> Also to comment Chris Dollin's remark. The idiomatic way of doing this 
>> is not to write the name of the file in the body of 'if' but instead 
>> construct the readfromLog() interface in a way it returns error codes 
>> which are processed by the caller.
>>
> 
> Then the same problem will appear in the caller. You will have to keep 
> that information in a associative list (or in a structure containing the
> file) , then modify a lot of interfaces to pass an extra parameter or
> a different structure than FILE *.

It is up to the user of the functionality you're creating to do what it 
finds appropriate.

It would be a diversion from the main topic to be finicky on the example 
you gave, but just to avoid abstractions: in the case of hypothetical 
readFromLog(), how many logs would be in an application? Isn't easier to 
the programmer call the function with a wrapper readUsersLog, 
readMaterialsLog, etc., and then just give a hard coded (in the wrapper) 
"Error reading users log.", etc.?

> 
> This is not possible when you are writing a library (and can't ask the
> user to pass you the file name because the user may not know it, or
> did not store it, etc)

My central comment and critic here is that your design of the library is 
not correct.

In some place was this file opened and the name known, the common way of 
doing in C is to get back to caller.

> 
> This is a discussion where the principle of keeping related information
> in one place holds. The best place to keep the file name information is
> in the fopen function since it is that function the constructor of
> the FILE structure. Any other solution means a replication of effort
> that should be done when constructing the object.

A FILE structure can be obtained without a name. . .

> 
>> Also, the function [_]fname as proposed would have serious problems if 
>> you attempt to use it in a POSIX environment where FILE *fmemopen() or 
>> FILE *open_memstream() are expected to exist and they have no name 
>> assosiated with.
>>
> 
> How many times must I repeat the same thing? If there is no file name
> you can always return NULL (meaning there is no file name) or some
> made up name like "/\/\stdin/\/\"...

So how the user will know *what* NULL object is being the culprit? In 
the large what would be the advantage?

If your library requires a set of functions you feel to report file 
names, create a whole ensemble with the correct ones from start, like 
(say) MYFILE *openLog(), int readFromLog(), int closeLog(), etc.

Better, less surprises for users that want a conforming program to run 
compiled by your tools, and you have the API you're developing.

jacob navia wrote:
> [...]
> How many times must I repeat the same thing?

     Until everyone else stops repeating *their* same things?

     Honestly, people: This thread has already dragged on for
more than ten dozen posts spread over six days, and as far as
I can see *every* point was made within the first six hours.
The subsequent descent into brickbattery is unedifying.

-- 
Eric.Sosman@sun.com

jacob navia wrote:

> fopen() will save the file name and an accessor function
> will return the file name given a FILE *.

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

Reading this thread it is amazing how much negative reaction there is to
this idea.

Every possible objection has been raised against it (you'd think they had
been the ones asked to implement it!). The main one was that the 'filename'
was meaningless.

Various alternatives have been proposed which mostly involved the programmer
in doing extra work and which in some cases could have meant revising
millions of lines of existing code. In this case presumably the 'filename'
is no longer meaningless!

As I understand it:

* This feature requires the programmer to do nothing different
* There is available a new /optional/ function such as fname()

So the programmer can use fname() /or/ can do whatever he does now.

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

So what is the problem? (I understand that fname() may be restricted to a
particular implementation.)

-- 
bartc

jacob navia skrev:
> CBFalconer wrote:
>> If you just want the name under which the file was opened, save
>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> the strcpy function.

[...]

> Now ALL the interfaces to ALL the functions that could need this
> information (or that call a function that could need this
> information) need their interface CHANGED to have ONE EXTRA PARAMETER!
> 
> This is completely impossible to do in complex systems!

Nonsense, here is a real-world example, not very complex, just a batch 
gateway I wrote (an ISO format in, a "CPRF" and response file out):

struct param
{
         const char  *fname_iso;
         FILE        *f_iso;
         const char  *fname_cprf;
         FILE        *f_cprf;
         const char  *fname_resp;
         FILE        *f_resp;
         const char  *fname_log;
         FILE        *f_log;
};

and in case of batch reject error, the system clean up (temporary) 
output files by using the file name like this:

static void err_batch_reject(struct param *p)
{
         int rc = SUCCESS;

         fclose(p->f_cprf);
         fclose(p->f_resp);

         if (0 != remove(p->fname_cprf) )
         {
                 file_log(E_ERROR, "remove error of '%s'", 
NOT_NULL(p->fname_cprf));
                 rc = E_IO_REMOVE;
         }
         if (0 != remove(p->fname_resp) )
         {
                 file_log(E_ERROR, "remove error of '%s'", 
NOT_NULL(p->fname_resp));
                 rc = E_IO_REMOVE;
         }

         fclose(p->f_iso);
         fclose(p->f_log);

         exit(BATCH_REJECT);
}


Now, notice that the output files are closed, then deleted, so your 
_fname() will not help much. I assume you free the file name on 
fclose(), right?

Finally, this GW run on Solaris... so using _fname() will break the program.

OTOH, if using lcc-win, program will be bloated by 4x extra malloc's, 4x 
extra free's, and more memory usage.... for no gain at all.

For "complex" systems, this is a useless extension.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

"Richard Heathfield" <rjh@see.sig.invalid> schreef in bericht 
news:ULSdndKsJOlyE__VRVnyvgA@bt.com...
> Serve Lau said:
>
>>
>> "Chris Dollin" <chris.dollin@hp.com> schreef in bericht
>> news:g3tmvu$q14$1@news-pa1.hpl.hp.com...
>>> CBFalconer wrote:
>>>
> <snip>
>>>>
>>>> If you just want the name under which the file was opened, save
>>>> that at fopen time.
>>>
>>> That doesn't help ONE LITTLE BIT if some OTHER piece of code
>>> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
>>> somewhere. In that case everyone's RANTING that YOU CAN DO IT
>>> YOURSELF is revealed as a FINE CASE OF missing the POINT;
>>> you /can't/ do it yourself, because in general you can't
>>> refactor all the code.
>>
> <snip>
>>
>> Or did you mean with code you have no control over that the one who
>> maintains the software containing openfile is working in the same
>> company? You have learnt to talk.
>
> That won't help if you don't have the authority to request a change, or if
> the library writer has gone out of business leaving you with a legacy lib
> and no budget to rewrite it.
>
>> If you are too afraid to ask them to
>> change it you can still do it yourself.
>
> Not if you're being paid to do other stuff.
>
>> MYFILE f;
>> f.name = "test.txt";
>> f.fp = openfile(f.name);
>>
>> that wasnt so hard to do even when you dont have control over openfile
>
> Strawman. Now consider a library written by someone else, one that 
> provides
> you with a file pointer but where you don't get to provide the filename.
> Consider, for example:
>
> FILE *open_config_file(int subprogramID);
>
> where the decision about which config file to open is taken from you.

No problem.

printf("Could not read from config file opened by subProgramID %d\n", 
subprogramID);

Then check documentation what file "subprograms" use or just use your brain 
given the context. But I guess for the sake of argument we dont have 
documentation now and we had way too much to drink yesterday and lost our 
brain...then call the people who made the library...if their phones are 
suddenly broken e-mail them what files that id could open. But yeah they use 
outlook which is from microsoft so it sucks and never works then install 
filemon which can show you the file that you tried to read.
Its a silly discussion. Once again, storing the filename in the FILE struct 
is nothing more than moving the job of application programmers into system 
libraries

Serve Lau said:

> 
> "Richard Heathfield" <rjh@see.sig.invalid> schreef in bericht
> news:ULSdndKsJOlyE__VRVnyvgA@bt.com...
<snip>
>> Consider, for example:
>>
>> FILE *open_config_file(int subprogramID);
>>
>> where the decision about which config file to open is taken from you.
> 
> No problem.
> 
> printf("Could not read from config file opened by subProgramID %d\n",
> subprogramID);

Yes, you can find a solution, but it isn't a solution that gives you access 
to the filename, whereas Mr Navia's solution could give you that access:

fp = open_config_file(42);
if(NULL == fp)
{
  printf("Could not open configuration file %s.\n", _fname(fp));

<snip>

> Its a silly discussion.

Not as silly as some we've had here, not by a long way.

> Once again, storing the filename in the FILE
> struct is nothing more than moving the job of application programmers
> into system libraries

Personally, I think it's short-sighted to lock oneself into implementation 
extensions unless one really really must, and so a wise programmer will 
generally design his code in such a way as to allow him to minimise such 
dependencies. That said, it is of course in implementors' interests to 
provide extensions that they hope will attract customers. If Mr Navia 
wants to provide an _fname function, that's entirely up to him.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Bartc" <bc@freeuk.com> writes:

> Ben Bacarisse wrote:
>> jacob navia <jacob@nospam.com> writes:
>
>> Not necessarily.  The most common solution is to wrap a FILE * in a
>> struct that has the extra data.  In several programs of mine, the name
>
>>> This is completely impossible to do in complex systems!
>>
>> That is over-stating the case.  It is not impossible.  If you know of
>> anyone who believes this and has money to spare, let me know.
>
> If you're distributing a library of some kind (it could be dynamic or 
> static), and want to update one of the functions so that it can make use of 
> the filename of a file-handle, then your solution would involve all the 
> thousands of users of your library in updating their code.

That is entirely true.  In fact it shows that, given the right
restrictions (library using code needs only a re-link), it is
impossible even in simple systems.  Jacob's point seemed to that it
was the complexity that made it impossible.

-- 
Ben.

Tor Rustad wrote:
> Now, notice that the output files are closed, then deleted, so your 
> _fname() will not help much. I assume you free the file name on 
> fclose(), right?
> 

name = strdup(fname(fp));
fclose(fp);
delete(name);
free(name);

> Finally, this GW run on Solaris... so using _fname() will break the 
> program.
> 

Names beginning with underscore are reserved for the implementation.

> OTOH, if using lcc-win, program will be bloated by 4x extra malloc's, 4x 
> extra free's, and more memory usage.... for no gain at all.
> 

Why 4?

Just one

> For "complex" systems, this is a useless extension.
> 

Do not think so

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Richard Heathfield wrote:
> Serve Lau said:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> schreef in bericht
>> news:ULSdndKsJOlyE__VRVnyvgA@bt.com...
> <snip>
>>> Consider, for example:
>>>
>>> FILE *open_config_file(int subprogramID);
>>>
>>> where the decision about which config file to open is taken from
>>> you.
>>
>> No problem.
>>
>> printf("Could not read from config file opened by subProgramID %d\n",
>> subprogramID);
>
> Yes, you can find a solution, but it isn't a solution that gives you
> access to the filename, whereas Mr Navia's solution could give you
> that access:
>
> fp = open_config_file(42);
> if(NULL == fp)
> {
>  printf("Could not open configuration file %s.\n", _fname(fp));

Since fp is NULL at this point, fname will need to be pretty clever.

-- 
Bartc

Bartc said:

> Richard Heathfield wrote:
<snip>
>>
>> Yes, you can find a solution, but it isn't a solution that gives you
>> access to the filename, whereas Mr Navia's solution could give you
>> that access:
>>
>> fp = open_config_file(42);
>> if(NULL == fp)
>> {
>>  printf("Could not open configuration file %s.\n", _fname(fp));
> 
> Since fp is NULL at this point, fname will need to be pretty clever.

<g> Sorry, good spot there. Okay, so amend the example to:

fp = open_config_file(42);
if(NULL != fp)
{
  while(whatever(fp, args) != NULL)
  {
    dostuffwith(args);
  }
  if(ferror(fp))
  {
    printf("Could not dostuffwith configuration file %s.\n", _fname(fp));
 

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia skrev:
> Tor Rustad wrote:
>> Now, notice that the output files are closed, then deleted, so your 
>> _fname() will not help much. I assume you free the file name on 
>> fclose(), right?
>>
> 
> name = strdup(fname(fp));
> fclose(fp);
> delete(name);
> free(name);

That add another malloc + free call, and require extra coding.


>> Finally, this GW run on Solaris... so using _fname() will break the 
>> program.
>>
> 
> Names beginning with underscore are reserved for the implementation.

Yes, and it do remind users of a compiler _not_ to use such functions.

>> OTOH, if using lcc-win, program will be bloated by 4x extra malloc's, 
>> 4x extra free's, and more memory usage.... for no gain at all.
>>
> 
> Why 4?
> 
> Just one

Hmm..why one?

In this case, it was 4 files to open, and 4 files to close. Do you 
optimize away these malloc/free's, for FILE that _fname() isn't used?

Some programs open and close a logfile on every write, not that this 
matter much these days, as the world get more and more IO bound.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

jacob navia wrote:
> CBFalconer wrote:
>
>> If you just want the name under which the file was opened, save
>> that at fopen time.  No load on the library, no muss, no fuss.  See
>> the strcpy function.
> 
> Yes sure. And how do the other functions that need this information
> will be able to get it????
> 
> int readfromLog(FILE *fp) {
>         char buf[512];
>         size_t bufsiz=sizeof(buf);
>         int s = fread(buf,1,bufsiz,fp);
>         if (s <= 0) {
>                 // How do I get the name of the file here Mr Falconer?
>         }
> }
> 
> You see the problem?

For example, create a thing:

  typdef struct fdata {
     FILE *f;
     char *fn;
  } fdata;

and replace your FILE * variables with that.  Initialize the
structures of that type to NULL and NULL.  Now you can store all
the data you require, no impingement on the standard, etc.  If you
want to pass the structure onward you can write:

   int getcx(fdata *ff) {
      int ch;
      if (EOF == (ch = getc(ff->f)) {
         printf("EOF received from %s\n", ff-?fn);
         /* here you can access whatever you wish */
      }
      return ch;
   }

or whatever is really needed.  You can make your own version of
fopen that initializes the fn field (use a deep copy of the actual
string).  Now it is never attempting to do the impossible.  No
tables needed.

The real point is that there are absolute impossibilities involved
in providing the ability in general through the system library. 
There are no difficulties in providing things at the user level
where the user can see exactly what is happening.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

vippstar@gmail.com wrote:
> Chris Dollin <chris.dol...@hp.com> wrote:
>
.... snip ...
>
>> That doesn't help ONE LITTLE BIT if some OTHER piece of code
>> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
>> somewhere. In that case everyone's RANTING that YOU CAN DO IT
>> YOURSELF is revealed as a FINE CASE OF missing the POINT;
>> you /can't/ do it yourself, because in general you can't
>> refactor all the code.
>
> In that case you expect that OTHER piece of code to also save
> the filename, IF it is ever going to be needed.  If it is
> indeed going to be needed but the OTHER piece of code does
> not save it, then it's most likely bad code.
>
> When I use code from someone else, a library for example, I
> expect him to have thought out all the design issues.  If he
> has not done so, I can either e-mail him about it, contribute
> code, use it as is, or move on to the next library.  I /won't/
> expect my compiler to have feature X to save me.

Nonsense.  You open the file, saving the name you used.  Another
process deletes the filename you used.  You still have the file
open, but the name is worthless.  The file still exists.  You can
copy it elsewhere, or do all sorts of things to it.  Under
Unix/Linux/Posix, but not Winders.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

Bartc wrote:
> jacob navia wrote:
> 
>> fopen() will save the file name and an accessor function
>> will return the file name given a FILE *.
>> 
>> What would be the best name for this function?
>> char *fname(FILE *); // lower case, short, similar to other
>>                      // file functions
> 
.... snip ...
> 
> So what is the problem? (I understand that fname() may be
> restricted to a particular implementation.)

The problem is that such non-implementable things do not belong in
the system library.  If they are user code in a library
"FunnyStuffToRnOnMyUnusualSystem.lib" or equivalent, no problem.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

On Jun 24, 2:28=A0am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.com> wrote:
> > How often do people want to associate a file name with a FILE object? =
=A0
>
> every time there's an error reading a file.
>
> Error: inifile_read.c line 230: parse error reading "BLOB_COUNT"


Actually that illustrates the objection.  It's not the FILE object
that's the center of this process, it's the C compiler's read_a_line
function, which is part of the read_source_file_xxx group of
functions.  These may happen to use fopen, and fread or fgets to
actually physically retrieve in the input line, but they have to
maintain other stuff as well.  For example the line number so that you
can produce error messages.  Then the read_a_line function will
provide the higher levels of the compiler some way to associate a
particular point in the input stream with that data, so that a
meaningful error message can be produced.

[I dropped comp.compilers.lcc from the newsgroups line.]

In article <Y3y8k.15793$E41.3023@text.news.virginmedia.com>
Bartc <bc@freeuk.com> wrote:
>Reading this thread it is amazing how much negative reaction there is to
>this idea.

Possibly because of the person who proposed it, but possibly also
or instead because the idea has been tried before and found wanting. :-)

>* This feature requires the programmer to do nothing different
>* There is available a new /optional/ function such as fname()
>
>So the programmer can use fname() /or/ can do whatever he does now.
>
>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).
>
>So what is the problem? (I understand that fname() may be restricted to a
>particular implementation.)

There is nothing fundamentally wrong with the idea.  As at least
a few people have pointed out, it helps out in the case of files
that were opened by "bad" code ("bad" is somewhat subjective of
course) that fails to save the name even though the name is useful
later.  If the implementation saves the name for you, you can work
around the bad code -- rather than fixing it -- in those places
were you want to retrieve the name by which the file was opened.

This part is, I think, straightforward enough and something on
which everyone agrees.

The objections are:

  - The name may be "out of date" (due to file renames and so on).
    This is of course true, but not really relevant: in a situation
    in which you would have saved the name, then printed the one
    *you* saved, you would be printing that same out-of-date name.

  - The name may be unavailable, because the "fopen()" equivalent
    was done in a way that did not provide a name (e.g., via fdopen()
    on a system that supports it -- this includes many Windows-based
    systems -- or the operation is done on stdin, stdout, or stderr).
    This is also true, but again perhaps not so relelvant: in
    a situation in which you would have saved the name, then printed
    the one *you* saved, you might well have the same problem.  (Or
    you might not, in the case of fdopen() for instance.)  So this
    objection is slightly more relevant.

  - The "implementation question", as I will call it: how does the
    implementation actually implement the name-saving?

    A typical stdio "FILE *" pointer points to a structure with a
    number of fields that are accessed via macros and/or functions:

        typedef struct __sFILE FILE;
        struct __sFILE {
            ... various fields ...
        };

    The "obvious" way to implement _fname is:

        FILE *fopen(const char *restrict name, const char *restrict mode) {
            FILE *retval;

            ... all the usual work ...
            ... assume we are now ready to succeed here ...
            retval->__sname = name;
            return retval;
        }

        const char *_fname(FILE *fp) {
            return fp->__sname;
        }

    The problem with this implementation is that the pointer saved
    in fopen(), and returned by _fname(), is valid only as long as
    the storage for the name-string passed to fopen().  If -- as is
    typical -- the name is in an automatic-duration buffer, the
    pointer _fname() will return becomes invalid as soon as that
    automatic-duration variable is destroyed.  In something reasonably
    close to half the calls to fopen(), this has happened by the
    time you (the programmer who would use _fname()) would get
    around to calling _fname().  So *this* implementation will not
    help you.

    The implementation can, of course, simply use something similar
    to the (nonstandard) strdup() function:

            retval->__sname = strdup(name);
            return retval;
        }

    but now the cost is less trivial: the implementor now must not
    only add a pointer to each FILE object, but also allocate space
    to hold the name.  The implementor must also make sure to free()
    the space when the FILE is fclose()d.

    This objection is not so much an "objection" as a "point of
    view".  Is it reasonable to have the C library routine do the
    strdup() (or equivalent)?  If not, is the pointer-only version
    of fname() going to be useful enough?

  - Lastly, there is the "utility question", which is something of
    an expanded version of the previous question.  Even if the C
    library fopen() routine does do a strdup()-or-equivalent, so
    that a non-NULL return from _fname() actually points to a
    useable string, is knowing the name alone sufficient?  In many
    (but not all) cases, a diagnostic that prints only the name of
    the file is not terribly useful.  If you want to print a file
    name and line number, or file name and character offset, or
    file name and nearby contents, you need a bit more.  The
    character offset can be (non-portably, alas) obtained via
    fseek(), ftell(), or fgetpos(), but the others require more
    forethought and design -- and if you apply this forethought
    and design, you do not need _fname().

    (Note that when using forethought and design, the programmer
    can save the name even when using fdopen(), tell whether or
    not there is any need to strdup() the name, update it if the
    file is renamed on purpose, and so on.  The code also works on
    every implementation, not just those that provide _fname().
    So this option is a clear winner, if it is an option at all.)

So it really boils down to: a quick-and-dirty save-only-the-pointer
implementation is cheap, but not very useful.  A strdup()-the-string
implementation is less cheap, but more useful.  In my opinion, the
second version still does not reach the "90% useful" level that makes
it worth adding.  The first has lower cost, but does not even make
it to "40% useful" (again in my opinion).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

On 25 Jun, 18:05, vipps...@gmail.com wrote:
> On Jun 25, 7:51 pm, jacob navia <ja...@nospam.com> wrote:

<snip>

> > [...] My solution, that needs
>
> > =A0 =A0 =A0 =A0 name =3D _fname(fp);

<snip sarcasm>

> So you are adding features to your compiler to save your users some
> typing?

that's what compilers *do*!!!
I've programmed in assembler (it's quite fun) but I prefer
HLLs.

> Why don't you write a text editor instead of a compiler Mr Navia?

plonk!


--
Nick Keighley

On 25 Jun, 23:36, CBFalconer <cbfalco...@yahoo.com> wrote:

<snip>

> Nonsense. =A0You open the file, saving the name you used. =A0Another
> process deletes the filename you used. =A0You still have the file
> open, but the name is worthless. =A0The file still exists. =A0You can
> copy it elsewhere, or do all sorts of things to it. =A0Under
> Unix/Linux/Posix, but not Winders.

its hardly Jacob's fault if this bug is still present
in Unix...


:-)


--
Nick Keighley

"Chris Torek" <nospam@torek.net> wrote in message
news:g3vfoj086c@news2.newsguy.com...

> In article <Y3y8k.15793$E41.3023@text.news.virginmedia.com>
> Bartc <bc@freeuk.com> wrote:
>>Reading this thread it is amazing how much negative reaction there is to
>>this idea.
>
> Possibly because of the person who proposed it, but possibly also
> or instead because the idea has been tried before and found wanting. :-)

Well I can live without the feature myself, but I don't see much harm in it.

> There is nothing fundamentally wrong with the idea.  As at least
> a few people have pointed out, it helps out in the case of files
> that were opened by "bad" code ("bad" is somewhat subjective of
> course) that fails to save the name even though the name is useful
> later.  If the implementation saves the name for you, you can work
> around the bad code -- rather than fixing it -- in those places
> were you want to retrieve the name by which the file was opened.
>
> This part is, I think, straightforward enough and something on
> which everyone agrees.

I think this feature is more one of convenience, especially if there is some
'distance' between the fopen() and subsequent uses.

Pointing out that the name /could/ have been saved is (a bit) like saying
ftell() is not necessary because a good programmer would have kept track of
a file position by the number of bytes read or written so far.


> The objections are:
>
>  - The name may be "out of date" (due to file renames and so on).

The specification was that this is the name passed to fopen().

>  - The name may be unavailable, because the "fopen()" equivalent
>    was done in a way that did not provide a name (e.g., via fdopen()

>  - The "implementation question", as I will call it: how does the

>    The "obvious" way to implement _fname is:

[by storing the pointer]
Well, to me that is immediately obvious that is a bad way to do it. Anything
other than a constant string passed to fopen could be problematic.

>    The implementation can, of course, simply use something similar
>    to the (nonstandard) strdup() function:
....
>    but now the cost is less trivial: the implementor now must not
>    only add a pointer to each FILE object, but also allocate space
>    to hold the name.  The implementor must also make sure to free()
>    the space when the FILE is fclose()d.

Because /file/ operations are involved, the performance hit is likely to be
trivial. Memory use I have a feeling is not that significant either.

Perhaps an alternative fopen(), say fopen2(), should be used that does copy
the filename. Then the regular fopen() works as normal. The only difference
is that FILE reserves space for a char* field, set to NULL for a normal
fopen().

>  - Lastly, there is the "utility question", which is something of
>    an expanded version of the previous question.  Even if the C
>    library fopen() routine does do a strdup()-or-equivalent, so
>    that a non-NULL return from _fname() actually points to a
>    useable string, is knowing the name alone sufficient?  In many
>    (but not all) cases, a diagnostic that prints only the name of
>    the file is not terribly useful.

A filename is a good starting point! But the proposed fname() may not be
helpful here:

In one example that came up in this thread: if a library function calls
fopen() on your behalf, supplying it's own name, and propagates back a NULL
return value, fname() cannot retrieve the filename from this. So fname()
would only be useful when an fopen() succeeds.

-- 
Bartc

On Jun 26, 11:54 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 25 Jun, 18:05, vipps...@gmail.com wrote:
>
> > On Jun 25, 7:51 pm, jacob navia <ja...@nospam.com> wrote:
>
> <snip>
>
> > > [...] My solution, that needs
>
> > >         name = _fname(fp);
>
> <snip sarcasm>
>
> > So you are adding features to your compiler to save your users some
> > typing?
>
> that's what compilers *do*!!!
> I've programmed in assembler (it's quite fun) but I prefer
> HLLs.
Wrong, that's not what compilers or HLL (high level languages) do.
They are not designed to just save you some typing.
> > Why don't you write a text editor instead of a compiler Mr Navia?
>
> plonk!

CBFalconer <cbfalconer@yahoo.com> writes:

> vippstar@gmail.com wrote:
>> Chris Dollin <chris.dol...@hp.com> wrote:
>>
> ... snip ...
>>
>>> That doesn't help ONE LITTLE BIT if some OTHER piece of code
>>> NOT UNDER YOUR CONTROL fopened the file and plopped the FILE*
>>> somewhere. In that case everyone's RANTING that YOU CAN DO IT
>>> YOURSELF is revealed as a FINE CASE OF missing the POINT;
>>> you /can't/ do it yourself, because in general you can't
>>> refactor all the code.
>>
>> In that case you expect that OTHER piece of code to also save
>> the filename, IF it is ever going to be needed.  If it is
>> indeed going to be needed but the OTHER piece of code does
>> not save it, then it's most likely bad code.
>>
>> When I use code from someone else, a library for example, I
>> expect him to have thought out all the design issues.  If he
>> has not done so, I can either e-mail him about it, contribute
>> code, use it as is, or move on to the next library.  I /won't/
>> expect my compiler to have feature X to save me.
>
> Nonsense.  You open the file, saving the name you used.  Another
> process deletes the filename you used.  You still have the file
> open, but the name is worthless.  The file still exists.  You can
> copy it elsewhere, or do all sorts of things to it.  Under
> Unix/Linux/Posix, but not Winders.

What is Winders? Is it like Windows which you use?

Nick Keighley wrote:
> CBFalconer <cbfalco...@yahoo.com> wrote:
> 
> <snip>
> 
>> Nonsense.  You open the file, saving the name you used.  Another
>> process deletes the filename you used.  You still have the file
>> open, but the name is worthless.  The file still exists.  You can
>> copy it elsewhere, or do all sorts of things to it.  Under
>> Unix/Linux/Posix, but not Winders.
> 
> its hardly Jacob's fault if this bug is still present in Unix...

It's not a bug.  It is a deliberate practice.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

In article <g3vfoj086c@news2.newsguy.com>,
Chris Torek  <nospam@torek.net> wrote:

>In article <Y3y8k.15793$E41.3023@text.news.virginmedia.com>
>Bartc <bc@freeuk.com> 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

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
[...]
> Traditionally on unix systems the empty string refers to the current
> directory, and you can, on some systems and some filesystems, fopen()
> it.  However, this is such a special case that simply setting the
> "special string" to something like "(empty)" would handle it.

But "(empty)" is a valid file name.

-- 
Keith Thompson (The_Other_Keith) 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"

In article <lzfxr0yogl.fsf@stalkings.ghoti.net>,
Keith Thompson  <kst-u@mib.org> wrote:

>> Traditionally on unix systems the empty string refers to the current
>> directory, and you can, on some systems and some filesystems, fopen()
>> it.  However, this is such a special case that simply setting the
>> "special string" to something like "(empty)" would handle it.

>But "(empty)" is a valid file name.

Look back at the thread: "special string" refers to the stuff after
the null.  The normal case is

   / f o o / b a r \0

If the filename is not known, you get (for example)

  \0 . . s t d i n . . \0

Twink noted this would be ambiguous if the filename really was the empty
string, so I suggested that in that case you would get

  \0 ( e m p t y ) \0

to distinguish it.

So it doesn't matter that "(empty)" is a possible file name.

-- Richard
-- 
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <lzfxr0yogl.fsf@stalkings.ghoti.net>,
> Keith Thompson  <kst-u@mib.org> wrote:
> 
> >> Traditionally on unix systems the empty string refers to the current
> >> directory, and you can, on some systems and some filesystems, fopen()
> >> it.  However, this is such a special case that simply setting the
> >> "special string" to something like "(empty)" would handle it.
> 
> >But "(empty)" is a valid file name.
> 
> Look back at the thread: "special string" refers to the stuff after
> the null.  The normal case is
> 
>    / f o o / b a r \0
> 
> If the filename is not known, you get (for example)
> 
>   \0 . . s t d i n . . \0
> 
> Twink noted this would be ambiguous if the filename really was the empty
> string, so I suggested that in that case you would get
> 
>   \0 ( e m p t y ) \0
> 
> to distinguish it.
> 
> So it doesn't matter that "(empty)" is a possible file name.

You're right, I didn't make the connection.

You'd need to guarantee that, if the function returns (a pointer to)
an empty string, the '\0' is actually followed by a string.

And I agree with your earlier comment that it's ugly.  (I used a
similar trick a few years ago as part of my IOCCC entry.)

-- 
Keith Thompson (The_Other_Keith) 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"

Eric Sosman wrote:
> Walter Roberson wrote:
> > I do not have my C89 hardcopy here to check against. I know
> > that there are various routines that are marked with wording
> > similar to "The implementation shall behave as if no library
> > routine calls <name>".

They are often in relation to modification of static duration objects.

> > I do not recall if malloc() is one of those routines ?
>
>      No, it is not.  Lots of fopen() implementations, for
> example, obtain I/O buffers from malloc().

Some even use malloc to obtain the FILE pointers.

--
Peter

"Eric Sosman" <esosman@ieee-dot-org.invalid> schreef in bericht 
news:NdCdnRpNZeQdysDVnZ2dnUVZ_t3inZ2d@comcast.com...
> Walter Roberson wrote:
>> In article <g3j9aq$14pa$1@pc-news.cogsci.ed.ac.uk>,
>> Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>>> In article <cc5e9$485d14c1$541fc2ec$13064@cache2.tilbu1.nb.home.nl>,
>>> Serve Lau <nihao@qinqin.com> wrote:
>>
>>>> But anyway, how will you store the strings? You cant store pointers so 
>>>> you have to go for string copying. But how large will you make the 
>>>> arrays you will copy the names into?
>>
>>> How about the right length?  Are you suggesting that there's some
>>> reason why fopen() shouldn't malloc() the space?
>>
>> I do not have my C89 hardcopy here to check against. I know that there
>> are various routines that are marked with wording similar to
>> "The implementation shall behave as if no library routine
>> calls <name>". I do not recall if malloc() is one of those routines ?
>
>     No, it is not.  Lots of fopen() implementations, for
> example, obtain I/O buffers from malloc().

But when you dont want to use malloc there is a mechanism in place to 
provide your own I/O buffer.

setbuf/setvbuf

Resource heavy software like commercial games do not use malloc, they often 
implement their own memory manager. Adding the filename inside FILE now 
introduces an obligatory malloc that wont be used. So I'm thinking if 
fname() gets added to lcc then also add a setfnamebuf(FILE *, char *).

And I still didnt see an answer to my question if there will be a wide char 
version for fname too. lcc provides a wfopen function and the return value 
is also a FILE * so you have no way of telling with which function the file 
was opened.

"Richard Heathfield" <rjh@see.sig.invalid> schreef in bericht 
news:4YidnUixqKpJL__VnZ2dnUVZ8sbinZ2d@bt.com...
> Yes, you can find a solution, but it isn't a solution that gives you 
> access
> to the filename, whereas Mr Navia's solution could give you that access:
>
> fp = open_config_file(42);
> if(NULL == fp)
> {
>  printf("Could not open configuration file %s.\n", _fname(fp));
>
> <snip>
>
>> Its a silly discussion.
>
> Not as silly as some we've had here, not by a long way.

I meant the argument for adding filename to FILE so you can get the name 
even if you have no control over some piece of code that returns FILE * is 
silly. When using software that isnt under your control it is important to 
write portable code and using fname is not smart then. When the software is 
not under your control your code will break if that software switches 
compilers.

and indeed as others pointed out, the snippet above shows another problem.

you cant do this:

fp = fopen("test", "r");
if(NULL == fp)
{
 printf("Could not open configuration file %s.\n", _fname(fp));
}

So you have to remember the filename yourself at some point anyway! I see 
lots of arguments against adding filename to FILE and only 1 in favor which 
is a little typing convenience.

Serve Lau said:

> "Richard Heathfield" <rjh@see.sig.invalid> schreef in bericht
> news:4YidnUixqKpJL__VnZ2dnUVZ8sbinZ2d@bt.com...
>> Yes, you can find a solution, but it isn't a solution that gives
>> you access to the filename, whereas Mr Navia's solution could
>> give you that access:
>>
>> fp = open_config_file(42);
>> if(NULL == fp)
>> {
>>  printf("Could not open configuration file %s.\n", _fname(fp));
>>
>> <snip>
>>
>>> Its a silly discussion.
>>
>> Not as silly as some we've had here, not by a long way.
> 
> I meant the argument for adding filename to FILE so you can get the name
> even if you have no control over some piece of code that returns FILE *
> is silly.

It's still not as silly as some arguments we've had here, by several orders 
of magnitude.

> When using software that isnt under your control it is
> important to write portable code and using fname is not smart then. When
> the software is not under your control your code will break if that
> software switches compilers.

You make a reasonable point. Note that I'm not sold one way or the other on 
this extension. Implementors *will* do this kind of thing whether we agree 
or not, but it does no real harm. It's like pizza, really. Some pizza 
places will put themselves to the trouble of providing a wide variety of 
toppings - broccoli, calamari, pear, salami, pepperoni, bacon, kiwi, 
mushrooms, goat cheese, red pepper, cryptosporidium, and so on - on the 
basis that they hope to attract a wide variety of customers that way. Me? 
I don't care (except about the last one, maybe) - as long as they do ANSI 
Standard Pizza (ham and pineapple piled on so high that it starts to 
slide), I'm perfectly happy. Likewise, who gives a stuff whether _fname is 
implemented, under whatever name? If you don't like it, don't use it.

<snip>
 
> So you have to remember the filename yourself at some point anyway!

My point was that you might not even *know* the filename, in which case you 
wouldn't be able to remember it.

> I see
> lots of arguments against adding filename to FILE and only 1 in favor
> which is a little typing convenience.

It's up to the implementation. If it's there, fine, I can ignore it. And if 
it isn't there, that's fine too - I can ignore it just as easily.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <a4b54$48651e78$541fc2ec$18525@cache3.tilbu1.nb.home.nl>,
Serve Lau <nihao@qinqin.com> wrote:

>Resource heavy software like commercial games do not use malloc, they often 
>implement their own memory manager. Adding the filename inside FILE now 
>introduces an obligatory malloc that wont be used.

And just what problem will this cause in practice?

The idea that "resource heavy" games might be significantly affected by
a few dozen malloc()ed bytes for each open file seems implausible, to
say the least.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

Richard Tobin wrote:
> In article <a4b54$48651e78$541fc2ec$18525@cache3.tilbu1.nb.home.nl>,
> Serve Lau <nihao@qinqin.com> wrote:
> 
>> Resource heavy software like commercial games do not use malloc, they often 
>> implement their own memory manager. Adding the filename inside FILE now 
>> introduces an obligatory malloc that wont be used.
> 
> And just what problem will this cause in practice?
> 
> The idea that "resource heavy" games might be significantly affected by
> a few dozen malloc()ed bytes for each open file seems implausible, to
> say the least.
> 
> -- Richard

That kind of software uses megabytes of memory easily, but they do
not open a lot of files, just a few configuration files, images
and such, never more than (say) 100 files opened at the same
time at most. With an average path length of say 100 we have
around 10K.

BIG DEAL!


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
> That kind of software uses megabytes of memory easily, but they do
> not open a lot of files, just a few configuration files, images
> and such, never more than (say) 100 files opened at the same
> time at most. With an average path length of say 100 we have
> around 10K.
> 
> BIG DEAL!

This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
forget that a lot of C programming nowadays is done in embedded
environments where memory is scare. I've recently worked on programming a
coffee maker where the total available RAM was 16K. I definitely don't
want to have 10K wasted storing garbage I don't want.

Chris Peters wrote:
> On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
>> That kind of software uses megabytes of memory easily, but they do
>> not open a lot of files, just a few configuration files, images
>> and such, never more than (say) 100 files opened at the same
>> time at most. With an average path length of say 100 we have
>> around 10K.
>>
>> BIG DEAL!
> 
> This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
> forget that a lot of C programming nowadays is done in embedded
> environments where memory is scare. I've recently worked on programming a
> coffee maker where the total available RAM was 16K. I definitely don't
> want to have 10K wasted storing garbage I don't want.
> 

In that case please do not open 100 files simultaneously!

That was for the 100 files case :-)

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Chris Peters said:

> On Fri, 27 Jun 2008 23:16:56 +0200, jacob navia wrote:
>> That kind of software uses megabytes of memory easily, but they do
>> not open a lot of files, just a few configuration files, images
>> and such, never more than (say) 100 files opened at the same
>> time at most. With an average path length of say 100 we have
>> around 10K.
>> 
>> BIG DEAL!
> 
> This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
> forget that a lot of C programming nowadays is done in embedded
> environments where memory is scare. I've recently worked on programming a
> coffee maker where the total available RAM was 16K. I definitely don't
> want to have 10K wasted storing garbage I don't want.

Whilst I sympathise with the idea of economic memory usage, it's probably 
fair to point out that Mr Navia is not even proposing a change to the 
standard library, let alone that subset of it that embedded systems are 
required to provide, but rather an extension for a Windows-only 
implementation. I know that 10K is still 10K, but it's not such a great 
percentage of available memory on a typical Windows system as it would be 
on an embedded system.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <pan.2008.06.27.21.29.55.681312@spam.com>,
Chris Peters  <no@spam.com> wrote:

>This kind of reckless squandering of memory causes BIG PROBLEMS. Don't
>forget that a lot of C programming nowadays is done in embedded
>environments where memory is scare.

Is it impossible to retain context over a couple of articles?  We were
addressing a claim about "resource heavy games".

Jacob is considering an addition to a general-purpose Windows C
compiler.  The requirements of embedded environments are irrelevant.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

"jacob navia" <jacob@nospam.com> schreef in bericht 
news:g43lce$omk$1@aioe.org...
> Richard Tobin wrote:
>> In article <a4b54$48651e78$541fc2ec$18525@cache3.tilbu1.nb.home.nl>,
>> Serve Lau <nihao@qinqin.com> wrote:
>>
>>> Resource heavy software like commercial games do not use malloc, they 
>>> often implement their own memory manager. Adding the filename inside 
>>> FILE now introduces an obligatory malloc that wont be used.
>>
>> And just what problem will this cause in practice?
>>
>> The idea that "resource heavy" games might be significantly affected by
>> a few dozen malloc()ed bytes for each open file seems implausible, to
>> say the least.
>>
>> -- Richard
>
> That kind of software uses megabytes of memory easily, but they do
> not open a lot of files, just a few configuration files, images
> and such, never more than (say) 100 files opened at the same
> time at most. With an average path length of say 100 we have
> around 10K.
>
> BIG DEAL!

its what microsoft said when creating vista. BIG DEAL everybody has 2GB 
these days.
its what driver writers say. BIG DEAL
its what every writer of your service or daemon you currently have running 
is saying. BIG DEAL.
every program in your taskbar. BIG DEAL.
every normal program running. BIG DEAL.

Everybody says it these days.

Also, on windows things gets converted to unicode whether you want it or 
not.

CBFalconer schrieb:

> All you have to do is mount the DJGPP system ls command.

What means that?

What is bad about ls?

Hans Schneider wrote:
> CBFalconer schrieb:
> 
>> All you have to do is mount the DJGPP system ls command.
> 
> What means that?

It means mount the portion of the DJGPP system that includes the ls
command.
> 
> What is bad about ls?

Nothing.  Why do you assume so?

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer skrev:

[...]

> Nonsense.  You open the file, saving the name you used.  Another
> process deletes the filename you used.  You still have the file
> open, but the name is worthless.  The file still exists.  You can
> copy it elsewhere, or do all sorts of things to it.  Under
> Unix/Linux/Posix, but not Winders.

 From C point-of-view, if the file is open, the behaviour of a remove()
call is implementation defined.


FYI, the implementation in this case is lcc-win.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

jacob navia wrote:
> Richard Tobin wrote:
>> In article <a4b54$48651e78$541fc2ec$18525@cache3.tilbu1.nb.home.nl>,
>> Serve Lau <nihao@qinqin.com> wrote:
>>
>>> Resource heavy software like commercial games do not use malloc, they 
>>> often implement their own memory manager. Adding the filename inside 
>>> FILE now introduces an obligatory malloc that wont be used.
>>
>> And just what problem will this cause in practice?
>>
>> The idea that "resource heavy" games might be significantly affected by
>> a few dozen malloc()ed bytes for each open file seems implausible, to
>> say the least.
>>
>> -- Richard
> 
> That kind of software uses megabytes of memory easily, but they do
> not open a lot of files, just a few configuration files, images
> and such, never more than (say) 100 files opened at the same
> time at most. With an average path length of say 100 we have
> around 10K.
> 
> BIG DEAL!


Really? I'm in a gaming project, a remake of a classic turn-based WW2
strategy game.


Today we load the complete map of a scenario from a single file, BUT
ideas has been put forward, to generate the scenario map from some basic
image building blocks instead.

Also, there are thousands of icons, which are overlayed on the map, each
icon has multiple variants for different orientation, to give player a
sense of dynamics in movement of units.

The icon file has grown to >50 MB and is still growing, we will consider
moving this into a central repository... and splitting it into multiple
files, so that players don't have to download everything, when more
icons are added.

Depending on future design decisions, there might be WAY MORE than 100
files to open... our map database has today around 1000 full-scale maps.

When adding features like _fname(), there will be a cost, the main thing
might not even the extra bloat by mem usage, but that this trigger more
cache misses, worse branch prediction etc. etc.

This is QoI issues, and I'm sure you have a set of benchmarks to detect
such side-effects...

One of the reasons to use C, is for the programmer to decides for 
themselves when bloat is acceptable, and when it is not.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

In article <IM2dneV_n_wzH_rV4p2dnAA@telenor.com>,
Tor Rustad  <bwzcab@wvtqvm.vw> wrote:

>The icon file has grown to >50 MB and is still growing, we will consider
>moving this into a central repository... and splitting it into multiple
>files, so that players don't have to download everything, when more
>icons are added.
>
>Depending on future design decisions, there might be WAY MORE than 100
>files to open... our map database has today around 1000 full-scale maps.

Why would all the icon files be open at once?  That seems like a
stupid design decision, and additional space for the filenames would
be the least of your problems.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

I may be misunderstanding the situation, but what's wrong with the
user getting the data from the struct himself?
i.e.:
  FILE *fd = fopen(name,mode);
  printf ("file name is %s\n", fd.FileName);

I also agree with Chris in that it would be wasting a lot of memory.

Richard Tobin wrote:
> In article <IM2dneV_n_wzH_rV4p2dnAA@telenor.com>,
> Tor Rustad  <bwzcab@wvtqvm.vw> wrote:
> 
>> The icon file has grown to >50 MB and is still growing, we will consider
>> moving this into a central repository... and splitting it into multiple
>> files, so that players don't have to download everything, when more
>> icons are added.
>>
>> Depending on future design decisions, there might be WAY MORE than 100
>> files to open... our map database has today around 1000 full-scale maps.
> 
> Why would all the icon files be open at once?  That seems like a
> stupid design decision, and additional space for the filenames would
> be the least of your problems.

Your interpretation, appear more stupid. :) FYI, I said "files to open", 
that don't mean all files would be open _at once_.  Agreed?

Anyway, as an AI programmer, it's not my call how to design this, but if 
it was my call....

I would look into using an embedded DB with B-trees locally, and in case 
of missing icons, downloaded these from a central repository and then 
insert the icons into the local DB.

Nevertheless, I have seen more than once, programmers using the 
filesystem, instead of pulling in some DB API.

-- 
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

In article <b684481d-7dba-4797-bf97-8ae6663eccb1@l64g2000hse.googlegroups.com>,
Nigel  <nigel.redding@gmail.com> wrote:
>I may be misunderstanding the situation, but what's wrong with the
>user getting the data from the struct himself?
>i.e.:
>  FILE *fd = fopen(name,mode);
>  printf ("file name is %s\n", fd.FileName);

You have declared fd as a FILE *, which is a pointer, but then
you then use direct structure dereferencing on that pointer
when you use fd.FileName . fd->FileName would be more likely to
compile.
-- 
  "Prevention is the daughter of intelligence."
                                              -- Sir Walter Raleigh

Walter Roberson wrote:
> Nigel  <nigel.redding@gmail.com> wrote:
>
>> I may be misunderstanding the situation, but what's wrong with
>> the user getting the data from the struct himself?
>> i.e.:
>>   FILE *fd = fopen(name,mode);
>>   printf ("file name is %s\n", fd.FileName);
> 
> You have declared fd as a FILE *, which is a pointer, but then
> you then use direct structure dereferencing on that pointer
> when you use fd.FileName . fd->FileName would be more likely to
> compile.

Ignoring the fact that you have no business dereferencing a FILE*
pointer yourself, what ever gave you the idea that that structure
has a FileName field?

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer <cbfalconer@yahoo.com> writes:

> Walter Roberson wrote:
>> Nigel  <nigel.redding@gmail.com> wrote:
>>
>>> I may be misunderstanding the situation, but what's wrong with
>>> the user getting the data from the struct himself?
>>> i.e.:
>>>   FILE *fd = fopen(name,mode);
>>>   printf ("file name is %s\n", fd.FileName);
>> 
>> You have declared fd as a FILE *, which is a pointer, but then
>> you then use direct structure dereferencing on that pointer
>> when you use fd.FileName . fd->FileName would be more likely to
>> compile.
>
> Ignoring the fact that you have no business dereferencing a FILE*
> pointer yourself, what ever gave you the idea that that structure
> has a FileName field?

Walter didn't. Try reading before you offer your dubious "insight". 

Nigel <nigel.redding@gmail.com> writes:
> I may be misunderstanding the situation, but what's wrong with the
> user getting the data from the struct himself?
> i.e.:
>   FILE *fd = fopen(name,mode);
>   printf ("file name is %s\n", fd.FileName);

You mean fd->FileName.

If it's an extension in a specific implementation, that wouldn't be an
unreasonable way to do it, I suppose.  Any code that refers to it is
going to be non-portable anyway.

If it were being proposed as an addition to the standard, though, I
wouldn't want to do it that way.  It would place additional
constraints on implementations, specifically that type FILE must be a
struct (or union, but that would be silly).  And it wouldn't fit in
well conceptually with everything else in <stdio.h> that takes FILE*
arguments and doesn't attempt to delve into the internals.

(To be clear, I don't think anybody has proposed adding this to the
standard.)

> I also agree with Chris in that it would be wasting a lot of memory.

I don't think it would be much of a problem, other than on small
embedded systems that don't necessarily support fopen() anyway.

-- 
Keith Thompson (The_Other_Keith) 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"

In article <4867E10F.CD3EB540@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:
>Walter Roberson wrote:
>> Nigel  <nigel.redding@gmail.com> wrote:

>>> I may be misunderstanding the situation, but what's wrong with
>>> the user getting the data from the struct himself?
>>> i.e.:
>>>   FILE *fd = fopen(name,mode);
>>>   printf ("file name is %s\n", fd.FileName);

>> You have declared fd as a FILE *, which is a pointer, but then
>> you then use direct structure dereferencing on that pointer
>> when you use fd.FileName . fd->FileName would be more likely to
>> compile.

>Ignoring the fact that you have no business dereferencing a FILE*
>pointer yourself, what ever gave you the idea that that structure
>has a FileName field?

I said "more likely to compile"; I didn't say "a good idea"
or anything else that should be taken as indicative of approval
of the method.

It is a matter of probabilities: each compiler has a limited number
of -possible- field names for a structure member, possibly
on the order of pow(53,31) or pow(53,127) for that compiler.
If the filename is (as is the premise of this thread) stored
in the FILE structure, then there is a field name for it, and
FileName has a 1 in pow(53,31) or pow(53,127) or whatever of
being that field name and thus that using fd->FileName would
compile to do what Nigel was hoping.

If, though, fd.FileName is used instead of fd->FileName, then
beyond the 1 in pow(53,31) or pow(53,127) (or whatever) chance,
the compiler, after detecting (and issuing a diagnostic for)
the constraint violation of fd.FileName, would have to choose to
continue compilation. That is a -possibility-, but the -probability-
that the compiler would choose that is something less than 1,
so using fd.FileName instead of fd->FileName would have a lower
probability of compiling than fd->FileName would -- which was
all that I stated.
-- 
  "I feel sorry for the person who can't get genuinely excited
  about his work. Not only will he never be satisfied, but he will
  never achieve anything worthwhile."         -- Walter Chrysler

In article <zrydnV8pbO_bRfrV4p2dnAA@telenor.com>,
Tor Rustad  <bwzcab@wvtqvm.vw> wrote:

>> Why would all the icon files be open at once?  That seems like a
>> stupid design decision, and additional space for the filenames would
>> be the least of your problems.

>Your interpretation, appear more stupid. :) FYI, I said "files to open", 
>that don't mean all files would be open _at once_.  Agreed?

Well, that would have been the natural interpretation, but in that
case what would the problem be with storing the file names?  The
amount of space required corresponds to the number of simultaneously
open files, not the total number ever opened.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

Richard Tobin wrote:
> In article <zrydnV8pbO_bRfrV4p2dnAA@telenor.com>,
> Tor Rustad  <bwzcab@wvtqvm.vw> wrote:
> 
>>> Why would all the icon files be open at once?  That seems like a
>>> stupid design decision, and additional space for the filenames would
>>> be the least of your problems.
> 
>> Your interpretation, appear more stupid. :) FYI, I said "files to open", 
>> that don't mean all files would be open _at once_.  Agreed?
> 
> Well, that would have been the natural interpretation, but in that

Instead of assuming others write something stupid, it's perhaps wise to 
reconsider your own smartness first.


> case what would the problem be with storing the file names?  The
> amount of space required corresponds to the number of simultaneously
> open files, not the total number ever opened.

FYI, an implementation of the standard C library free(), may or may not 
trigger a system call, which actually free the memory chunk allocated. 
Even if a program burn memory like a pig, modern OS'es will typically 
swap out unused memory pages anyway.


If the free() implementation is like you suggest, with an explicit 
system call for every free() call. Then, programs opening many files, 
might be slowed down by 1 extra system call per malloc(), and 1 extra 
system call per free(). That can become a lot of context switches... for 
no good reason at all.


The point is, bloated C compilers, are not very interesting to the 
gaming community, which a while back, used lcc for quite a different reason.

-- 
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

Richard wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
>> Walter Roberson wrote:
>>> Nigel  <nigel.redding@gmail.com> wrote:
>>>
>>>> I may be misunderstanding the situation, but what's wrong with
>>>> the user getting the data from the struct himself?
>>>> i.e.:
>>>>   FILE *fd = fopen(name,mode);
>>>>   printf ("file name is %s\n", fd.FileName);
                                    ^^^^^^^^^^^               
>>>
>>> You have declared fd as a FILE *, which is a pointer, but then
>>> you then use direct structure dereferencing on that pointer
>>> when you use fd.FileName . fd->FileName would be more likely to
>>> compile.     ^^^^^^^^^^^   ^^^^^^^^^^^^
>>
>> Ignoring the fact that you have no business dereferencing a FILE*
>> pointer yourself, what ever gave you the idea that that structure
>> has a FileName field?
> 
> Walter didn't. Try reading before you offer your dubious "insight".

Walter did.  Note the underlined referances.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer wrote:

> Richard wrote:
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>> Walter Roberson wrote:
>>>> Nigel  <nigel.redding@gmail.com> wrote:
>>>>
>>>>> I may be misunderstanding the situation, but what's wrong with
>>>>> the user getting the data from the struct himself?
>>>>> i.e.:
>>>>>   FILE *fd = fopen(name,mode);
>>>>>   printf ("file name is %s\n", fd.FileName);
>                                     ^^^^^^^^^^^
>>>>
>>>> You have declared fd as a FILE *, which is a pointer, but then
>>>> you then use direct structure dereferencing on that pointer
>>>> when you use fd.FileName . fd->FileName would be more likely to
>>>> compile.     ^^^^^^^^^^^   ^^^^^^^^^^^^
>>>
>>> Ignoring the fact that you have no business dereferencing a FILE*
>>> pointer yourself, what ever gave you the idea that that structure
>>> has a FileName field?
>> 
>> Walter didn't. Try reading before you offer your dubious "insight".
> 
> Walter did.  Note the underlined referances.

Note that "Nigel" was the one who first mentioned it. Walter Roberson
was just offering a correction.

In article <KbCdnebxjomgvvXV4p2dnAA@telenor.com>,
Tor Rustad  <bwzcab@wvtqvm.vw> wrote:

>> Well, that would have been the natural interpretation, but in that

>Instead of assuming others write something stupid, it's perhaps wise to 
>reconsider your own smartness first.

I just couldn't see how your point made any sense otherwise.

>> case what would the problem be with storing the file names?  The
>> amount of space required corresponds to the number of simultaneously
>> open files, not the total number ever opened.

>FYI, an implementation of the standard C library free(), may or may not 
>trigger a system call, which actually free the memory chunk allocated. 
>Even if a program burn memory like a pig, modern OS'es will typically 
>swap out unused memory pages anyway.

I still don't understand your point.  I know all that.

>If the free() implementation is like you suggest, with an explicit 
>system call for every free() call.

I haven't suggested anything like that at all.  I doubt there are
any such implementations.

>Then, programs opening many files, 
>might be slowed down by 1 extra system call per malloc(), and 1 extra 
>system call per free(). That can become a lot of context switches... for 
>no good reason at all.

Such an implementation would be very inefficient.  But presumably
Jacob's isn't such an implementation.

Just in case I'm still not clear, my point was that adding a malloc()
to fopen() (and a free() to fclose()) is not going to have a great cost
for large programs because it won't use much memory compared to that
already used, and won't take any significant time compared with the
overhead of opening a file.

>The point is, bloated C compilers, are not very interesting to the 
>gaming community, which a while back, used lcc for quite a different reason.

That might be *a* point, but the one I was addressing was much more
specific.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

CBFalconer <cbfalconer@yahoo.com> writes:

> Richard wrote:
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>> Walter Roberson wrote:
>>>> Nigel  <nigel.redding@gmail.com> wrote:
>>>>
>>>>> I may be misunderstanding the situation, but what's wrong with
>>>>> the user getting the data from the struct himself?
>>>>> i.e.:
>>>>>   FILE *fd = fopen(name,mode);
>>>>>   printf ("file name is %s\n", fd.FileName);
>                                     ^^^^^^^^^^^               
>>>>
>>>> You have declared fd as a FILE *, which is a pointer, but then
>>>> you then use direct structure dereferencing on that pointer
>>>> when you use fd.FileName . fd->FileName would be more likely to
>>>> compile.     ^^^^^^^^^^^   ^^^^^^^^^^^^
>>>
>>> Ignoring the fact that you have no business dereferencing a FILE*
>>> pointer yourself, what ever gave you the idea that that structure
>>> has a FileName field?
>> 
>> Walter didn't. Try reading before you offer your dubious "insight".
>
> Walter did.  Note the underlined referances.

Once more. Please read what you are replying to. Your contributions are
become more useless by the post. If you don't have anything to offer,
then keep quiet.

In article <g4ado0$bhk$2@registered.motzarella.org>,
Richard <rgrdev@gmail.com> wrote:
....
>Once more. Please read what you are replying to. Your contributions are
>become more useless by the post. If you don't have anything to offer,
>then keep quiet.

Excuse me.  If the regs stopped posting useless/wrong stuff, all you'd
hear in here would be crickets.

And where would be the fun in that?  I say: Keep it comin'!

gazelle@xmission.xmission.com (Kenny McCormack) writes:

> In article <g4ado0$bhk$2@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:
> ...
>>Once more. Please read what you are replying to. Your contributions are
>>become more useless by the post. If you don't have anything to offer,
>>then keep quiet.
>
> Excuse me.  If the regs stopped posting useless/wrong stuff, all you'd
> hear in here would be crickets.
>
> And where would be the fun in that?  I say: Keep it comin'!

Not true. Heathfield might be a pompous ass, but he does know his C and
can, at times, take a practical approach. Sometimes. I expect to seem
him get worse though as "vippstar" tries his best to dislodge him in the
"Indeed" stakes.

Richard Tobin wrote:
> In article <KbCdnebxjomgvvXV4p2dnAA@telenor.com>,
> Tor Rustad  <bwzcab@wvtqvm.vw> wrote:
> 
>>> Well, that would have been the natural interpretation, but in that
> 
>> Instead of assuming others write something stupid, it's perhaps wise to 
>> reconsider your own smartness first.
> 
> I just couldn't see how your point made any sense otherwise.

In the message you responded to, I said:

"When adding features like _fname(), there will be a cost,
the main thing might not even the extra bloat by mem usage,
but that this trigger more cache misses, worse branch
prediction etc. etc."


To spell it out: my main consern was NOT the extra SPACE required, but 
the TIME overhead. Regardless, I would add a benchmark with at least 10 
000 files to open and read, considering only 100 files, was way too little.


>>> case what would the problem be with storing the file names?  The
>>> amount of space required corresponds to the number of simultaneously
>>> open files, not the total number ever opened.
> 
>> FYI, an implementation of the standard C library free(), may or may not 
>> trigger a system call, which actually free the memory chunk allocated. 
>> Even if a program burn memory like a pig, modern OS'es will typically 
>> swap out unused memory pages anyway.
> 
> I still don't understand your point.  I know all that.


IF you did, then please explain how this make sense:

"The amount of space required corresponds to the number of 
simultaneously open files, not the total number ever opened."


FYI, assume that a program open X files, load the content of all X 
files, then close X files.

At this point, the "simultaneously open files" are only 3. If free() 
implementation has no explicit system call to free the space allocated, 
the memory required by the program at this point, does _not_ correspond 
to 3 files, but to

3 + X

files.

>> If the free() implementation is like you suggest, with an explicit 
>> system call for every free() call.
> 
> I haven't suggested anything like that at all.  I doubt there are
> any such implementations.

This statement

"The amount of space required corresponds to the number of 
simultaneously open files, not the total number ever opened."

only made sense to me, IF you suggested exactly that. Unlike others, I 
do assume that people are smart. :P

-- 
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

In article <KpidnS5iMetCkPTV4p2dnAA@telenor.com>,
Tor Rustad  <bwzcab@wvtqvm.vw> wrote:

>IF you did, then please explain how this make sense:
>
>"The amount of space required corresponds to the number of 
>simultaneously open files, not the total number ever opened."
>
>FYI, assume that a program open X files, load the content of all X 
>files, then close X files.

This seems to be the very "all open at once" interpretation which you
said was stupid.

>At this point, the "simultaneously open files" are only 3. If free() 
>implementation has no explicit system call to free the space allocated, 
>the memory required by the program at this point, does _not_ correspond 
>to 3 files, but to
>
>3 + X
>
>files.

Ok, the maximum number of simultaneously open files.  If you read the
files one after another (and close them as you go along), the memory
will be available to malloc() to reuse.  You would only need memory
for all 3+X if all 3+X were simultaneously open at some time, which is
why I asked why you would have all the icon files open at once.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

Richard Tobin wrote:
> In article <KpidnS5iMetCkPTV4p2dnAA@telenor.com>,
> Tor Rustad  <bwzcab@wvtqvm.vw> wrote:
> 
>> IF you did, then please explain how this make sense:
>>
>> "The amount of space required corresponds to the number of 
>> simultaneously open files, not the total number ever opened."
>>
>> FYI, assume that a program open X files, load the content of all X 
>> files, then close X files.
> 
> This seems to be the very "all open at once" interpretation which you
> said was stupid.

I said:

"Your interpretation, appear more stupid."

it was you who talked about _stupid_ design, I just made a relative 
assertion. Do you understand the difference?

FYI, I have not said yet, whether I consider it a stupid design or not.


>> At this point, the "simultaneously open files" are only 3. If free() 
>> implementation has no explicit system call to free the space allocated, 
>> the memory required by the program at this point, does _not_ correspond 
>> to 3 files, but to
>>
>> 3 + X
>>
>> files.
> 
> Ok, the maximum number of simultaneously open files.  

???

I give up, you contradict yourself too much, is 3 + X equal to the total 
number ever opened, or NOT?

You can't have it both ways, ref:

"The amount of space required corresponds to the number of 
simultaneously open files, not the total number ever opened."


-- 
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

In article <eL6dnWDsi50GuPTVRVnzvQA@telenor.com>,
Tor Rustad  <bwzcab@wvtqvm.vw> wrote:

>> Ok, the maximum number of simultaneously open files.  
>
>???
>
>I give up, you contradict yourself too much, is 3 + X equal to the total 
>number ever opened, or NOT?
>
>You can't have it both ways, ref:
>
>"The amount of space required corresponds to the number of 
>simultaneously open files, not the total number ever opened."

I'm sorry, I'm completely lost.  Perhaps someone else (if anyone's
bothered to follow it) could resolve the point.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

Richard wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
> 
.... snip ...
>
>> Walter did.  Note the underlined referances.
> 
> Once more. Please read what you are replying to. Your
> contributions are become more useless by the post. If you don't
> have anything to offer, then keep quiet.

Well, with my change in news-servers resulting in a new troll-file,
you have so far escaped installation.  No longer.  You are now
properly classified with Twink and McCormack.  Bye.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

"jacob navia" <jacob@nospam.com> a �crit dans le message de news: 
g3gkln$uhk$2@aioe.org...
> Johannes Bauer wrote:
>> jacob navia schrieb:
>>> 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...

You must be kidding ?  Even Microsoft implements a half decent POSIX 
interface to the OS, with extra _ prefixes.  Do you only rely on stdio FILE* 
for file I/O ?

-- 
Chqrlie ? 

"Bartc" <bc@freeuk.com> a �crit dans le message de news: 
BEv7k.13912$E41.12300@text.news.virginmedia.com...
>
> "Serve Lau" <nihao@qinqin.com> wrote in message 
> news:c8164$485daf34$541fc2ec$19083@cache5.tilbu1.nb.home.nl...
>>
>> "jacob navia" <jacob@nospam.com> schreef in bericht 
>> news:g3jucg$d04$1@aioe.org...
>>> 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.
>
> 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.

Jacob, did you consider this alternative ?

-- 
Chqrlie.