Package-private access checking in GCJ 3.3

[Ranjit Mathew <rmathew at hotmail dot com>]

Hi,

    As you guys know, package-private access checking in GCJ 3.3
and 3.4 is totally busted. I have found that making the 
following simple change to not_accessible_p( ) in parse.y 
*seems* to resolve the problem:
------------------------------ 8< ------------------------------
Index: parse.y
===================================================================
*** parse.y	Sun Jun  8 20:04:39 2003
--- parse.y	Sun Jun 15 21:25:00 2003
*************** not_accessible_p (reference, member, whe
*** 10141,10152 ****
      }
  
!   /* Default access are permitted only when occurring within the
!      package in which the type (REFERENCE) is declared. In other words,
!      REFERENCE is defined in the current package */
!   if (ctxp->package)
!     return !class_in_current_package (reference);
! 
!   /* Otherwise, access is granted */
!   return 0;
  }
  
--- 10141,10147 ----
      }
  
!   /* Default access is permitted only when occurring from within
!      the package in which the MEMBER is declared. */
!   return !class_in_current_package (DECL_CONTEXT (member));
  }
  
------------------------------ 8< ------------------------------

I made this change purely to make it consistent with the similar
check for protected access a few lines above in the same method
and not out of some profound understanding of what is 
happening. ;-)

I also noted that class_in_current_package( ) correctly handles
the case where the current class is in the default package.

This change however exposes another problem - we do not use
any bit to indicate package-private access and so 
java_accstring_lookup( ) returns the closest available set
flag, if any, and "" otherwise. This makes for some rather
confusing error messages. :-)

(BTW, we use the same bit for both ACC_SUPER and 
ACC_SYNCHRONIZED and these are the only two that share a
bit - is this by design or is this an oversight?)

I have only "bubblestrapped" with this change and tested 
against very simple testcases.

This is not a patch - merely fodder for thought - and is
taken against the 3.3 release.

Ranjit.

-- 
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,           
INDIA.               Web: http://ranjitmathew.tripod.com/