monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Killing off boost::fs


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Killing off boost::fs
Date: Mon, 1 Aug 2005 01:18:41 -0700
User-agent: Mutt/1.5.9i

On Mon, Aug 01, 2005 at 08:13:22AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Fri, 29 Jul 2005 20:49:33 -0700, Nathaniel 
> Smith <address@hidden> said:
> njs>   - one should not be able to instantiate a file_path directly.
> njs>     Instead there should be two constructors; one that takes (and
> njs>     requires) an already-normalized path, and one that takes an
> njs>     unnormalized path and normalizes it.  Doing this allows us to
> njs>     be more secure, and probably also faster, when dealing with
> njs>     important contexts (e.g., parsing revisions) where we _know_
> njs>     that the path should be normalized already.
> 
> I assume that in this case, you're not talking about the constructor
> methods, but about separate functions.  Otherwise, I don't quite
> understand what you mean with "not be able to instantiate a file_path
> directly".

Yeah, I'm thinking something like
  class file_path {
    private:
      file_path(std::string const & s);
      friend file_path file_path_from_normalized_string(std::string const &);
      friend file_path file_path_from_unnormalized_string(std::string const &);
  };
Those names can obviously use shortening... the point is that each
call should be explicit about what it expects.

> Speaking of normalised and not normalised, can't we simply assume that
> all paths we get as input aren't normalised?

Input from the user, yes.  But there are other strings -- for
instance, those encountered when parsing a revision, or manifest
-- that should be normalized, and it should be an error if they are
not.  Plus, maybe this would give speed improvements, verifying the
paths in manifests is slow.

> BTW, I assume that with "normalised", you're talking about removal of
> ../ when possible, tilde-expansion, compression of a sequence of / to
> one /, things like that.

Possibly also utf8 conversion; definitely also conversion of \ to / on
windows, ...

> njs>   - it might also make sense to have these constructors take care
> njs>     of the prefixing required to deal with calling monotone in a
> njs>     subdirectory
> 
> So basically, you want the notion of the top of a work directory tree.

Yeah.

> njs>   - the bookkeeping_path constructor should require an
> njs>     already-normalized path that begins "MT/", since we always
> njs>     generate these internally anyway.
> njs>   - system_path (maybe needs a better name?) should always be
> njs>     absolutified and tilde-expanded, and otherwise do not need to
> njs>     be verified.
> 
> Do we want any path to be tilde-expanded, or just the system_path?

Just system_path, I think; though possibly ~ should just be disallowed
in other paths... basically, one can think ~foo as being like /foo,
it's an absolute path.

> njs> We don't need many actual operations on these:
> njs>   - write file
> njs>   - read file
> 
> Uhm, just a small thing here; there already is iostream, so I'm going
> to assume you really mean "open", or possibly even just method that
> returns a localised string that represents the path to be used with
> normal iostream operations and whatnot.  Actual writing and reading
> should be left to iostream, IMHO.

Oh, sure -- or some other IO library (crypto libraries tend to come
with these).  But there should be a monotone function that does this,
is all.

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]