nogc v0.5.0 - DIP1008 works!
Atila Neves
atila.neves at gmail.com
Mon May 27 08:54:45 UTC 2019
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
> On 24.05.19 18:19, Atila Neves wrote:
>> On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
> [...]
>>> My `puts`s might not do any harm, but they could just as well
>>> be buffer overflows.
>>
>> Could you please give an example of how @system allocator code
>> could do that?
>
> Sure. You just write beyond some buffer instead of calling
> `puts`:
>
> ----
> char[3] buf;
> char[3] foo = "foo";
> char[3] bar = "bar";
>
> struct UnsafeAllocator
> {
> import std.experimental.allocator.mallocator: Mallocator;
> static instance = UnsafeAllocator.init;
> size_t i;
> void deallocate(void[] bytes) @nogc @system
> {
> buf.ptr[i .. i + 3] = '!';
> Mallocator.instance.deallocate(bytes);
> }
> void[] allocate(size_t sz) @nogc @system
> {
> buf.ptr[i .. i + 3] = '!';
> return Mallocator.instance.allocate(sz);
> }
> }
>
> void main() @safe @nogc
> {
> {
> import nogc: BUFFER_SIZE, text;
> UnsafeAllocator.instance.i = 8;
> /* greater than buf.length, whoops */
> auto t = text!(BUFFER_SIZE, UnsafeAllocator)(42);
> assert(foo == "foo"); /* fails */
> UnsafeAllocator.instance.i = 16;
> /* also greater than buf.length, whoops again */
> }
> assert(bar == "bar"); /* fails */
> }
> ----
>
> You just can't trust user-provided @system code. It doesn't
> matter if it's allocator code or whatever.
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.
The other issue is that Mallocator has a @safe allocate function
and a @system deallocate function since it's up to the user of
the interface to supply a slice that was actually malloc'ed. It's
clear that this interface is one that can be used @safely (and is
by automem.vector.Vector). Likewise, reallocating is @system
because there might be references to the old pointer, but it
makes sense that a @trusted block could exist where the reviewer
makes sure that there's only ever one reference to the allocated
memory.
Then there's the fact that if a 3rd party library really does
want to corrupt memory they can just tag all their functions with
@trusted, and unless someone looks at their code nobody will be
the wiser.
More information about the Digitalmars-d-announce
mailing list