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

[Bartc]

"Ian Collins" <ia******@hotmail.comwrote in message
news:6c*************@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

[Dik T. Winter]

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

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

It would be completely obscure if the filename does not contain the
complete path. Where in the file system does the program want to
write? What can I do to correct it?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Walter Roberson]

In article <Uh*******************@text.news.virginmedia.com >,
Bartc <[e-mail]:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:6c*************@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

[Walter Roberson]

In article <aP******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

[Richard Heathfield]

Walter Roberson said:

In article <aP******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

[CBFalconer]

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

[Peter Nilsson]

Keith Thompson wrote:

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

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.hdoesn't.

In my own case, rather than modify the C library, I have an
alternate header that wraps over <stdio.hto 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

[CBFalconer]

Peter Nilsson wrote:

Keith Thompson wrote:

>jacob navia <ja***@nospam.comwrites:

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

[Ben Bacarisse]

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

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.

[jacob navia]

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

[Chris Dollin]

CBFalconer wrote:

Peter Nilsson wrote:

>Keith Thompson wrote:

>>jacob navia <ja***@nospam.comwrites:

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

[vippstar]

On Jun 25, 5:55 pm, jacob navia <[e-mail]:

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?

[Ben Bacarisse]

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

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.

[vippstar]

On Jun 25, 6:07 pm, Chris Dollin <[e-mail]:

CBFalconer wrote:

Peter Nilsson wrote:

Keith Thompson wrote:
jacob navia <[e-mail]:

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

[Bartc]

Ben Bacarisse wrote:

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

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

[jacob navia]

vi******@gmail.com wrote:

On Jun 25, 5:55 pm, jacob navia <[e-mail]:

>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

[vippstar]

On Jun 25, 7:51 pm, jacob navia <[e-mail]:

[e-mail] wrote:

On Jun 25, 5:55 pm, jacob navia <[e-mail]:

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?

[Richard]

vi******@gmail.com writes:

On Jun 25, 7:51 pm, jacob navia <[e-mail]:

>[e-mail] wrote:

On Jun 25, 5:55 pm, jacob navia <[e-mail]:
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.

[Cesar Rabak]

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

[Serve Lau]

"Chris Dollin" <ch**********@hp.comschreef in bericht
news:g3**********@news-pa1.hpl.hp.com...

CBFalconer wrote:

>Peter Nilsson wrote:

>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:

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

[Richard Heathfield]

Serve Lau said:

>
"Chris Dollin" <ch**********@hp.comschreef in bericht
news:g3**********@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

[jacob navia]

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

[Ian Collins]

jacob navia wrote:

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

[rio]

"jacob navia" <ja***@nospam.comha scritto nel messaggio
news:g3**********@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

[Cesar Rabak]

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.

[Eric Sosman]

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.

--
Er*********@sun.com

[Bartc]

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

[Tor Rustad]

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 <bw****@wvtqvm.vw | tr i-za-h a-z>

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:UL*********************@bt.com...

Serve Lau said:

>>
"Chris Dollin" <ch**********@hp.comschreef in bericht
news:g3**********@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

[Richard Heathfield]

Serve Lau said:

>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:UL*********************@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

[Ben Bacarisse]

"Bartc" <[e-mail]:

Ben Bacarisse wrote:

>jacob navia <ja***@nospam.comwrites:

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

[CBFalconer]

Ben Bacarisse wrote:

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

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

[jacob navia]

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

[Bartc]

Richard Heathfield wrote:

Serve Lau said:

>>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:UL*********************@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

[Richard Heathfield]

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.

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

[Tor Rustad]

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 <bw****@wvtqvm.vw | tr i-za-h a-z>

[CBFalconer]

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

[CBFalconer]

vi******@gmail.com wrote:

Chris Dollin <[e-mail]:

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

[CBFalconer]

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

[robertwessel2]

On Jun 24, 2:28*am, Nick Keighley <[e-mail]>
wrote:

On 24 Jun, 06:46, Ian Collins <[e-mail]:

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"

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.

[Chris Torek]

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

In article <Y3******************@text.news.virginmedia.com>
Bartc <[e-mail]:

>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) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Nick Keighley]

On 25 Jun, 18:05, [e-mail] wrote:

On Jun 25, 7:51 pm, jacob navia <[e-mail]:

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

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

plonk!
--
Nick Keighley

[Nick Keighley]

On 25 Jun, 23:36, CBFalconer <[e-mail]:

<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...
:-)
--
Nick Keighley

[Bartc]

"Chris Torek" <no****@torek.netwrote in message
news:g3********@news2.newsguy.com...

In article <Y3******************@text.news.virginmedia.com>
Bartc <[e-mail]:

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

[vippstar]

On Jun 26, 11:54 am, Nick Keighley <[e-mail]>
wrote:

On 25 Jun, 18:05, [e-mail] wrote:

On Jun 25, 7:51 pm, jacob navia <[e-mail]:

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

[Dik T. Winter]

In article <1214426072.859259@news1nwkEric Sosman <Er*********@sun.comwrites:

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.

Oh, peanuts. In sci.math there is a thread with over 7000 articles spead
over many months and not only has *every* point made in the first day,
every point was already made in tht newsgroup before the first article
was posted.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard]

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

vi******@gmail.com wrote:

>Chris Dollin <[e-mail]:

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

[CBFalconer]

Nick Keighley wrote:

CBFalconer <[e-mail]:

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

[Walter Roberson]

In article <g3********@news2.newsguy.com>,
Chris Torek <no****@torek.netwrote:

>In article <Y3******************@text.news.virginmedia.com>
Bartc <[e-mail]:

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

[Keith Thompson]

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