How broken ReadOnlyPointer is...

I've spent the last hour trying to fix this ptr_test testsuite
failure. I looked at the commit log to respect what was the intent of
the current implementation, but no matter how I fix it, the test case
or the implementation itself, it stays broken one way or another.
Especially the commit claim that different invocations of
write_access() never return null once it returned non-null is
impossible with regard to memory leaks. You can't know if you got a
copy (must be deleted) or the original (is deleted by the ROP
container). I also wonder if it's still useful in the current data
flow architecture, ie in which case is a copy not returned ?

I think we need something like that to pass on large data structures
safely in process, but if the unit test/implementation ain't fixed
real soon now, I'll just remove it and wait for a resubmission.

Peter

How broken ReadOnlyPointer is...

Peter Soetens wrote:
> I've spent the last hour trying to fix this ptr_test testsuite
> failure. I looked at the commit log to respect what was the intent of
> the current implementation, but no matter how I fix it, the test case
> or the implementation itself, it stays broken one way or another.
>
> Especially the commit claim that different invocations of
> write_access() never return null once it returned non-null is
> impossible with regard to memory leaks. You can't know if you got a
> copy (must be deleted) or the original (is deleted by the ROP
> container). I also wonder if it's still useful in the current data
> flow architecture, ie in which case is a copy not returned ?
>
> I think we need something like that to pass on large data structures
> safely in process, but if the unit test/implementation ain't fixed
> real soon now, I'll just remove it and wait for a resubmission.
>
I'll fix it in Barcelona. It is actually fixed in my 1.x fork, but I
have absolutely no time working on RTT 2

Sylvain