Getting the file name from a FILE *

jacob navia

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

Questions:

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

// clear name but maybe too long?
char *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

Jun 27 '08

Subscribe Post Reply

185

6839

jacob navia

Richard Tobin wrote:

In article <19***************************@cache5.tilbu1.nb.ho me.nl>,
Serve Lau <ni***@qinqin.comwrote:

>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

Jun 27 '08 #51

jacob navia

Serve Lau wrote:

>
"jacob navia" <ja***@nospam.comschreef in bericht
news:g3**********@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

Jun 27 '08 #52

Richard Tobin

In article <g3**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

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

Jun 27 '08 #53

Richard Heathfield

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

Jun 27 '08 #54

jacob navia

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

Jun 27 '08 #55

Richard Heathfield

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

Jun 27 '08 #56

Serve Lau

"jacob navia" <ja***@nospam.comschreef in bericht
news:g3**********@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.

Jun 27 '08 #57

forkazoo

On Jun 20, 9:11*am, jacob navia <ja...@nospam.comwrote:

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

Questions:

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

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

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

Jun 27 '08 #58

Keith Thompson

Tor Rustad <to********@hotmail.comwrites:

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) ks***@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"

Jun 27 '08 #59

Richard Heathfield

[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 <to********@hotmail.comwrites:
>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

Jun 27 '08 #60

Tor Rustad

Keith Thompson skrev:

Tor Rustad <to********@hotmail.comwrites:
>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 <bw****@wvtqvm.vw | tr i-za-h a-z>

Jun 27 '08 #61

Keith Thompson

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

Tor Rustad <to********@hotmail.comwrites:

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) ks***@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"

Jun 27 '08 #62

Bartc

"Serve Lau" <ni***@qinqin.comwrote in message
news:c8***************************@cache5.tilbu1.n b.home.nl...

>
"jacob navia" <ja***@nospam.comschreef in bericht
news:g3**********@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

Jun 27 '08 #63

CBFalconer

forkazoo wrote:

jacob navia <ja...@nospam.comwrote:

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

Jun 27 '08 #64

CBFalconer

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

Jun 27 '08 #65

Richard Bos

CBFalconer <cb********@yahoo.comwrote:

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.

Jun 27 '08 #66

Nick Keighley

On 22 Jun, 02:47, "Serve Lau" <ni...@qinqin.comwrote:

"jacob navia" <ja...@nospam.comschreef in berichtnews:g3**********@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

Jun 27 '08 #67

Richard Tobin

In article <5d**********************************@c58g2000hsc. googlegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:

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

Jun 27 '08 #68

Richard

Richard Heathfield <rj*@see.sig.invalidwrites:

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?

Jun 27 '08 #69

Richard

CBFalconer <cb********@yahoo.comwrites:

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

Jun 27 '08 #70

jacob navia

Richard wrote:

CBFalconer <cb********@yahoo.comwrites:

>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

Jun 27 '08 #71

John Bode

On Jun 23, 6:09 am, jacob navia <ja...@nospam.comwrote:

Richard wrote:
CBFalconer <cbfalco...@yahoo.comwrites:

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?

Jun 27 '08 #72

jacob navia

John Bode wrote:

On Jun 23, 6:09 am, jacob navia <ja...@nospam.comwrote:
>Richard wrote:
>>CBFalconer <cbfalco...@yahoo.comwrites:
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

Jun 27 '08 #73

Ben Bacarisse

John Bode <jf********@gmail.comwrites:

On Jun 23, 6:09 am, jacob navia <ja...@nospam.comwrote:
>Richard wrote:
CBFalconer <cbfalco...@yahoo.comwrites:

>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

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.

Jun 27 '08 #74

Dik T. Winter

In article <g3**********@aioe.orgja***@nospam.org writes:
....

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.

ksh: ls -a
.. .. ..stderr.. ..stdin.. ..stdout..
ksh:
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Jun 27 '08 #75

Bartc

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

John Bode <jf********@gmail.comwrites:

>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

Jun 27 '08 #76

Lew Pitcher

In comp.lang.c, jacob navia wrote:

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

Jun 27 '08 #77

Richard Heathfield

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

Jun 27 '08 #78

Richard Tobin

In article <g3**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

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

Jun 27 '08 #79

Serve Lau

"Nick Keighley" <ni******************@hotmail.comschreef in bericht
news:5d**********************************@c58g2000 hsc.googlegroups.com...

On 22 Jun, 02:47, "Serve Lau" <ni...@qinqin.comwrote:
>"jacob navia" <ja...@nospam.comschreef in
berichtnews:g3**********@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.

Jun 27 '08 #80

Antoninus Twink

On 23 Jun 2008 at 17:23, Richard Tobin wrote:

In article <g3**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>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.

Jun 27 '08 #81

robertwessel2

On Jun 23, 9:22*am, jacob navia <ja...@nospam.comwrote:

I repeat: fname returns the first argument of fopen.

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

Jun 27 '08 #82

Ben Bacarisse

Richard Heathfield <rj*@see.sig.invalidwrites:

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.

Jun 27 '08 #83

Richard Tobin

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

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

Jun 27 '08 #84

CBFalconer

jacob navia wrote:

John Bode wrote:
>jacob navia <ja...@nospam.comwrote:
>>Richard wrote:
CBFalconer <cbfalco...@yahoo.comwrites:

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

Jun 27 '08 #85

Richard Tobin

In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

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

Jun 27 '08 #86

William Ahern

Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

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.

Jun 27 '08 #87

CBFalconer

Richard Tobin wrote:

CBFalconer <cb********@maineline.netwrote:

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

Jun 27 '08 #88

William Ahern

jacob navia <ja***@nospam.comwrote:

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.

Jun 27 '08 #89

Ian Collins

CBFalconer wrote:

Richard Tobin wrote:
>CBFalconer <cb********@maineline.netwrote:

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

Jun 27 '08 #90

jacob navia

Ian Collins wrote:

CBFalconer wrote:
>Richard Tobin wrote:
>>CBFalconer <cb********@maineline.netwrote:

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

Jun 27 '08 #91

Ian Collins

jacob navia wrote:

Ian Collins wrote:
>CBFalconer wrote:
>>Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:

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

Jun 27 '08 #92

Nick Keighley

On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.comwrote:

CBFalconer wrote:
Richard Tobin wrote:
CBFalconer *<cbfalco...@maineline.netwrote:

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

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

Jun 27 '08 #93

Nick Keighley

On 24 Jun, 07:02, jacob navia <ja...@nospam.comwrote:

Ian Collins wrote:
CBFalconer wrote:
Richard Tobin wrote:
CBFalconer *<cbfalco...@maineline.netwrote:

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

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

Jun 27 '08 #94

Ian Collins

Nick Keighley wrote:

On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.comwrote:
>CBFalconer wrote:
>>Richard Tobin wrote:
CBFalconer <cbfalco...@maineline.netwrote:

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

Jun 27 '08 #95

Nick Keighley

On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.comwrote:

Nick Keighleywrote:
On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.comwrote:
CBFalconer wrote:
Richard Tobin wrote:
CBFalconer *<cbfalco...@maineline.netwrote:

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

Jun 27 '08 #96

Ian Collins

Nick Keighley wrote:

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

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

Jun 27 '08 #97

Richard

Nick Keighley <ni******************@hotmail.comwrites:

On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.comwrote:
>Nick Keighleywrote:
On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.comwrote:
CBFalconer wrote:
Richard Tobin wrote:
CBFalconer Â*<cbfalco...@maineline.netwrote:

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

Jun 27 '08 #98

Nick Keighley

On 24 Jun, 10:03, Richard<rgr...@gmail.comwrote:

Nick Keighley <nick_keighley_nos...@hotmail.comwrites:
On 24 Jun, 08:31, Ian Collins <ian-n...@hotmail.comwrote:
Nick Keighleywrote:
On 24 Jun, 06:46, Ian Collins <ian-n...@hotmail.comwrote:
CBFalconer wrote:
Richard Tobin wrote:
CBFalconer *<cbfalco...@maineline.netwrote:

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

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.

Jun 27 '08 #99

Richard Heathfield

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

Jun 27 '08 #100

Similar topics