Re: [Lit.] Buffer overruns

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 01/20/05 

Date: Wed, 19 Jan 2005 23:56:02 +0000 (UTC)

Paul Rubin wrote:
>I didn't realize it either. I thought that Java enforced private
>instance variables at all times. It looks like at least there's a
>convenient way to turn the protection ON.

I do know of one other way that the Java compiler fails to enforce
private instance variables: inner classes. Consider code like this:
    public class Foo {
        private int x;
        Foo() { ... }
        public class Bar {
            Bar() { ... }
            public void barMethod() { ... }
        }
    }
(I hope I got the syntax right.)
Obviously, the methods in Bar have access to 'x'. How do they get
that access? It turns out that the javac compiler transforms the
above code into a class Foo and another separate class called something
like Foo$Bar. This transformation is done because (I believe) JVML byte
code does not have any notion of nested classes. Then Foo$Bar needs
access to 'x', but because Foo$Bar is not a public class, it doesn't get
access by default. So what the compiler does is put Foo$Bar in the same
package as Foo and change the scope modifier on 'Foo.x' to be 'protected'
instead of 'private' so that Foo$Bar can access 'x'. Of course, this
has the undesireable consequence of allowing anyone else in the same
package as Foo to also access 'x', which is lame. However, this is
not a flaw of the JVML byte code or even (arguably) of the Java language,
so much as a flaw of javac's compilation strategy, I think.

As you say, the good news is that at least you can arrange to check
that these cheesy ways to subvert the type system are turned off. It
is a pretty easy syntactic check. Once you have confirmed that these
visibility holes are disabled, then you can do modular verification.

In contrast, in C the corresponding checks needed before you can do
modular verification are much harder. (For instance, they involve at
a minimum verifying that none of the code has any buffer overruns anywhere,
which is pretty much beyond the state of the art today unless you are
using some runtime system that provides automatic bounds checking.)

Relevant Pages

  • Re: changing access modifier of base method
    ... I'm not sure if this counts as a different meaning than your ... quality in the Java resources I've seen:)). ... design reason for making sealed the default. ... many more private members than public. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Some understanding questions...
    ... > must be private? ... class that has same namespace or not. ... In Java you should be able to do so ... Since there's the notion of "package private" too as I ...
    (microsoft.public.dotnet.vjsharp)
  • Re: camelCase
    ... you're hiding implementation *from the implementation*) ... I'd disagree in cases where the setter is performing validation, ... Everything is private unless there's a need for it to be protected ... Instance variables all start with "m_" (You can take the programmer ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Somewhat of a big lie about OO in java book?
    ... given that a separate set of instance variables is created ... in Java), then you aren't going to reach interesting conclusions. ... > book would be literally true, for example if there's a per-object way ... It's interesting to note that in a typical JavaScript implementation, ...
    (comp.lang.java.help)
  • Re: AspectJ: solution to Javas repetitiveness?
    ... becoming too familiar with Java. ... the amount of error-prone boilerplate code that programming in Java ... generated, the input to the generator is lost, and you have to read ... Perhaps for very simple classes whose instance variables are ...
    (comp.lang.java.programmer)