Re: [Sablevm-developer] Re: Compile issue

[Brent F. <bfu...@de...>]

On Sun, Dec 03, 2000 at 10:27:05AM -0500, Etienne M. Gagnon wrote:
> Hi Brent,
> 
> I am continuing this thread on the SableVM-Developer list.
> 
> Brent Fulgham wrote:
> > I've attached a diff for your review.  I wouldn't dare apply this to
> > the archive until you look at it.  It's probably pretty inefficient --
> > I think with some thought we could probably get rid of some copying.
> 
> I think you actually forgot to attach the diff (it happens to me often
> too, to forget attachments;-).
> 

Ack!  So I have.  Attaching now.

> If we implement this for --boot-class-path, we must also implement it
> for --boot-library-path.  We should also take care of adding a trailing
> "/" when necessary, e.g.:
> 
> (All of these should be valid)
> 
>  --boot-class-path=/usr/lib/sablepath/classes/:./  
>  --boot-class-path=/usr/lib/sablepath/classes:./  
>  --boot-class-path=/usr/lib/sablepath/classes/:.  
>  --boot-class-path=/usr/lib/sablepath/classes:.  
> 

Right -- I don't think this patch handles all such cases properly,
since it adds an extra '/' to the patch.  This is, of course,
easy to fix.  Although in practice I think the use of 
"[...]sablepath/classes//" just happens to work on most systems.

> If we want to accept "relative" paths (like "."), we should first
> convert them into absolute paths.  I do really dislike the JDK's
> vulnerability in this regard (as using a file dialog can change the
> current work directory and cause all sorts of problems).
> 
Okay.

> I don't know if it is a good thing, or not, to accept all of these
> things in the boot class path (see discussion below).  It might be
> sufficient to simply accept a single absolute path.
> 
Right -- with compile-time option so we don't always have to
pass it as a boot parameter.  Then --class-path would direct the
loader to our standard set of paths for classes.

(snipping rest of discussion, since I have nothing to add)

Thanks,

-Brent