Re: side note to ppfChdir

[Christian Reiniger <reiniger@rz.uni-wuerzburg.de>]

Pierre Phaneuf schrieb:

> > > As I understand, relative paths are a bit faster because the current
> > > working directory is already parsed and all... Removing the chdir()
> >
> > Not only that. The system also starts searching directly at the current
> > working dir.
> 
> This is a *very* minor optimization. I think the side-effect problem
> outweights this. I am not sure the system does starts searching directly
> at the current working dir, see later on...

Well, ppfChdir () exists to change the current working dir, so it should
in fact do that...
As an alternative we could store the path of the current dir as string
and turn all plain paths into proper absolute ones with this before
passing them to stdio. Which is really ugly.

> Libraries should aim to be as side-effect-free as possible, shouldn't
> they?

If the game wants to change directories it should be able to do that,
right?

> > What do you mean with security?
> 
> If you cache the open file descriptor to the pak file, you're losing
> Unix security semantics (which you might not care much about, as many
> other systems already lose some semantics, like NFS does with file
> opening semantics) in the simulated file system inside the pak file.
> 
> What I mean is that when you open a file, even with a relative path, the
> system checks your access right to every directory starting with the

Who would decide to remove reading rights for the PakFiles in the middle
of the game ?

> the fact that chdir() has nasty side-effects and that it doesn't
> actually help performance (and even if it did, it would be so marginal)
> just tell me you should ditch that.

As described above, doing the things without chdir () is even nastier.



	Christian