Getting the file name from a FILE *

[Richard Tobin]

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

And just what problem will this cause in practice?

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

-- Richard

 

[jacob navia]

And just what problem will this cause in practice?

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

-- Richard

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

BIG DEAL!

 

[Chris Peters]

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

BIG DEAL!

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

 

[jacob navia]

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

In that case please do not open 100 files simultaneously!

That was for the 100 files case

 

[Richard Tobin]

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

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

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

-- Richard

 

[Serve Lau]

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

BIG DEAL!

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

Everybody says it these days.

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

 

[Hans Schneider]

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

What means that?

What is bad about ls?

 

[CBFalconer]

What means that?

It means mount the portion of the DJGPP system that includes the ls
command.

What is bad about ls?

Nothing. Why do you assume so?

 

[Richard Tobin]

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

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

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

-- Richard

 

[Nigel]

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

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

 

[Walter Roberson]

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

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

 

[CBFalconer]

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

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

 

[Richard]

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

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

 

[Keith Thompson]

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

You mean fd->FileName.

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

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

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

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

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

 

[Walter Roberson]

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

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

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

If, though, fd.FileName is used instead of fd->FileName, then
beyond the 1 in pow(53,31) or pow(53,127) (or whatever) chance,
the compiler, after detecting (and issuing a diagnostic for)
the constraint violation of fd.FileName, would have to choose to
continue compilation. That is a -possibility-, but the -probability-
that the compiler would choose that is something less than 1,
so using fd.FileName instead of fd->FileName would have a lower
probability of compiling than fd->FileName would -- which was
all that I stated.

 

[Richard Tobin]

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

[/QUOTE]

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

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

-- Richard

 

[CBFalconer]

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

Walter did. Note the underlined referances.

 

[Dik T. Winter]

> In article <[email protected]>,

>
> And just what problem will this cause in practice?

When malloc is in conflict with their own memory manager.

 

[jacob navia]

When malloc is in conflict with their own memory manager.

Then they can't use lcc-win anyway since fopen calls malloc to
allocate the FILE structure.

 

[Richard Tobin]

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

[/QUOTE]

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

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

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

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

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

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

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

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

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

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

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

-- Richard