Re: Illegal Package-Private Accesses in 3.4

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > 
 > On Monday, Aug 11, 2003, at 09:23 Pacific/Auckland, Mark Wielaard wrote:
 > 
 > > Hi (discussion moved from java to java-patches),
 > >
 > > On Wed, 2003-07-09 at 21:35, Ranjit Mathew wrote:
 > >>     I applied my package-private access checking patch/kludge to
 > >> the 3.4 snapshot from 2007-07-02 and found that some of the
 > >> issues I had reported earlier in 3.3 have been resolved while
 > >> a new one has been added.
 > >>
 > >> The issues still present are:
 > >>
 > >>  2. java.lang.VMThrowable illegally calls "stackTraceAddrs( )"
 > >>     in gnu.gcj.runtime.StackTrace.
 > >
 > > It seems to me that the best thing to do is to move StackTrace to the
 > > java.lang package and make it package private to prevent any 'illegal'
 > > access to this class by user code.
 > 
 > Lets have a look at where stackTraceAddrs() is being used in 
 > VMThrowable:
 > 
 > 	NameFinder nameFinder = new NameFinder();
 > 	result = nameFinder.lookup(t, trace.stackTraceAddrs(),
 > 				   trace.length());
 > 
 > Since NameFinder and StackTrace are both in the same package, wouldn't 
 > a simpler solution be to pass "trace" itself and have NameFinder call 
 > the stackTraceAddrs?

Perhaps.

 > It would be cleaner to keep these things in the same package wherever 
 > possible. If we're worried about user code calling NameFinder being a 
 > security risk, we could add a security check to its constructor.

 > BTW, I notice some evil use of RawData & _Jv_Malloc in StackTrace. 
 > Specifically I don't see 'addrs' getting freed anywhere! I think its 
 > better to avoid RawData wherever possible, and use byte[] instead.

No, that's not right.  There are some severe problems with using
byte[] instead of RawData.  In particular, the previous equivalent of
this code broke because byte[] and pointer references have differing
alignments.  I suspect that the Right Thing here would be to create an
array of RawData instead of using _Jv_Malloc.

 > And maybe we should ban _Jv_Malloc from libgcj to enforce this ;-)

Andrew.