Re: side note to ppfChdir

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > Yes. It should use chdir() then. But doing this isn't an optimization or
> > just a handy way to shorten file names, it has side-effects on the
> > system (for example, the system would be unable to unmount a CD-ROM and
> 
> Well, the game needs the cd, so it accesses it and this in turn means it is
> locked. Sorry, there's nothing evil with that.

If the game is multi-CD and that on each CD there is a pak file,
unmounting the pak file will not suffice, the game will also have to
chdir() elsewhere to let the user change the CD-ROM. Developers will
easily find out and work around this, but this is the kind of annoying
stuff that make you ask yourself what the heck they were thinking...

If you have an open file (like the pak) on the CD, that's a better
indication of "needing" the CD I think...

> And the people for whom it makes sense to have core dumping enabled should
> be able to do a "find"...

Duh... I had to provide support by e-mail, and while I knew what was the
behavior of my game, if I had to support a game that did chdir()s all
over the place, I would say that it sucks.

> > What? Pre-pending the "virtual cwd" inside of PFile functions (where the
> > user doesn't see them) is nasty? Come on!
> 
> It at least means doing memory allocation and string copies quite
> frequently.

Give me a break... It'll get lost in the noise. You can come up with
some ways of improving this, for example, put the cwd in a buffer of
MAX_PATH size, all ready with the trailing slash, and strncpy the rest
there. Also, this is only for stdio files, because for files in a
pakfile, you could keep a pointer to the directory node directly and
work from there anyway.

No allocation is easy to do and no string copies are possible for the
most frequent case. What's the problem?

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi