Xojo.Core.MemoryBlock.Constructor( ptr ) is broken

If you create a Xojo.Core.MemoryBlock using Constructor( ptr ) or Constructor( ptr, size ), it cannot be returned properly by a function even though it seems fine in the method that created it.

For example, this does not work properly:

dim mb as new Xojo.Core.MemoryBlock( p, size )
return mb

This will:

dim mb as new Xojo.Core.MemoryBlock( p )
mb = mb.Left( size )
return mb

You will only see the issue when you examine the returned MemoryBlock in the calling method.

feedback://showreport?report_id=44530

Where is the ptr obtained from ?
Thats probably relevant

The pointer in StringToNewMemoryBlock_Fail is automatically “freed” at the end of the function. But I’m not really sure.

Hmm, hadn’t considered that. That makes sense with the vision that takes only a pointer, but what about pointer and size?

I shouldn’t post while standing in line at Starbucks. :slight_smile:

The constructor should retain the pointer in any event, no?

Norman, in the example app attached to the Feedback case, I obtained the Ptr from a classic MemoryBlock. As Eli noted, that classic MB goes out of scope at the end of the function that returns the new MB.

so I see

joe will probably need to review this one but he’s out sick today

OK
Spoke to Joe

Not a bug - in fact the new mb CANT take ownership of the Ptr - this is by design
What if it came from a DLL etc ?
We cannot take ownership of whatever memory this ptr points at because something else may own it

You’d need to copy the data to be safe

There may be a case for having a way to create from a Ptr AND copy - but thats not how it works today

So quite literally the memory block goes out of scope & gets deallocated & you have a dangling ptr in Xojo code

Thanks Norman. I’ll keep it in mind.

And now I see that it’s documented that way too. Considering how the rest of my day went, I’m wondering why I even bothered to get out of bed.

Please close the report as by design.

I already did :stuck_out_tongue: