On Monday, 27 May 2019 at 09:48:27 UTC, ag0aep6g wrote:
On 27.05.19 10:54, Atila Neves wrote:
I don't see the problem here. This example would throw
RangeError at runtime instead of actually overwriting memory
unless bounds checking is turned off.
No, it doesn't. It's a complete, runnable example. You can try
it at home. It does overwrite `foo` and `bar`. It does not
throw a RangeError.
You're right - I should have run it first.
Yes, you can use @trusted to use Mallocator safely. And your
code (probably) does that. But the allocator in my example
isn't Mallocator, it's UnsafeAllocator. Your code doesn't use
that one safely.
No, and I guess it can't. I'm trying to figure out what the
implications are. Can Vector only be @safe for Mallocator? Is it
possible to write a @safe Vector at all without having to force
the allocator to be @safe?
In this thread, you're the author of that 3rd party library.
You've got the bad @trusted functions that lead to memory
corruption. I'm the guy who looked at it, noticed the problem,
and tells you.
Thanks for bringing it up.
