Re: Illegal Package-Private Accesses in 3.4

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Monday, Aug 11, 2003, at 22:12 Pacific/Auckland, Andrew Haley wrote:
 > 
 > >> 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.
 > 
 > Doh. I presume we've tried to go down the path of giving the data field 
 > of all array types pointer alignment?

I thought of it, and then dismissed the idea fairly quickly.  It's
wasteful and unnecessary apart from these weird corner cases.

 > >  I suspect that the Right Thing here would be to create an
 > > array of RawData instead of using _Jv_Malloc.
 > 
 > Either that or JvAllocBytes, and introducing another RawData type which 
 > doesn't prevent the GC from marking it.

Well, how exactly could you do that?  RawData isn't necessarily a
pointer to memory that is accessible to the gc.

 > Maybe RawData should actually be marked, and we could have a
 > separate RawDataUnmarked for the cases where thats useful.

Umm.  Just using an array of RawData is surely the cleanest solution.

Andrew.