code:priv_dir()

[Vance Shipley]

Personally I don't see anything wrong with the description,
it's just semantics.  I read "path" as the code path which as
you relate is implemented in a code_names table.  This however
is one of those "you're not supposed to know that" things ala
the recent discussion of records.  If you read "path" as in 
$PATH, or something else, you would indeed get the wrong idea.

	-Vance

> -----Original Message-----
> From: Ulf Wiger [mailto:etxuwig@REDACTED]
> Sent: Thursday, December 06, 2001 4:40 AM
> To: Vance Shipley
> Cc: Bengt Kleberg; erlang-questions@REDACTED
> Subject: RE: code:priv_dir()
> 
> 
> On Wed, 5 Dec 2001, Vance Shipley wrote:
> 
> >	priv_dir(Name) -> PrivDir | {error, What}
> >
> >	This function returns the current priv directory for the
> >	Name[-*] directory. The current path is searched for a
> >	directory named .../Name-* (the -* suffix is optional for
> >	directories in the search path and it represents the version
> >	of the directory). The /priv suffix is added to the end of
> >	the found directory.
> 
> This description is not consistent with how it's actually
> implemented. The path is _not_searched when priv_dir/1 is called.
> Rather, when add_path/1 is called, the path to the Name[-*]
> directory is stored in a code_names table. The call to
> priv_dir(Name) will result in a lookup on that table; if Name
> does not exist there, {error, ...} is returned; otherwise, /priv
> is appended. No check is made to verify that Name/priv actually
> exists (which is as it should be). On the other hand, when
> code:add_path/1 is called, the supplied paths _are_ verified.