This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ and Java CNI: Check Java references
>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
Andrew> Anyway, it's just dawned on me that this solution could never
Andrew> work: the `this' pointer in C++ isn't a smart pointer, so
Andrew> references to instance data and methods would not be checked.
I think (unfortunately :-) that this won't be a problem because we'll
always know that this!=0 -- because if it were ==0 then the caller
would have caught it.
Actually, now I think you're right again. The problem is non-virtual
methods. You can make a non-virtual method call with a null `this'
and it will "work". In fact in gcj we have code to deal specially
with this, because we can't rely on MMU support in this case.
Last night I was thinking that maybe if we turned every pointer in CNI
into a reference then we could have gcjh add `operator *' to every
class automatically. But of course this doesn't work because we would
actually need `operator .', which C++ doesn't provide :-(.
What if we opted to use references everywhere but kept the source
using `->' to reference fields and such? That might be a little
confusing, but maybe we could arrange it so that attempts to use
`foo.field' rather than `foo->field' would fail.
Two things with this approach that I don't yet understand:
* Is there a performance impact for using references instead of
pointers as arguments to methods? It's hard to believe there would
be one, but I don't know for certain.
* I imagine on the gcj side we'd need to change (1) all the source
(change "*" to "&" all over the place), (2) change the compiler to
emit a different mangling for method arguments, and (3) change gcjh
to reflect the new reality.
* How are objects returned from methods handled?
I think this approach does handle the nonvirtual method call problem,
because operator-> must still be used to compute `this'.
Unfortunately this approach still requires a huge amount of work to
implement.
Tom