This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]