[CallerMustBeUnsafe] type attribute

[benaadams]

To mark a function to be only be able to be called in an unsafe block.

It came up as an issue with having an IntPtr based api for Vector.Copy be equally could apply to something like a .ctor where you are passing an internal buffer to use (e.g. https://github.com/dotnet/coreclr/issues/3142)

Or risk of use of buffers with overlapped I/O tasks and dispose dotnet/corefx#5954 (comment)

To indicate that the caller is aware there are risks and to be careful.

[jkotas]

This is what security transparent vs. security critical code has been about...

[benaadams]

I might have missed it then; but what I am suggesting is something where .ctor 2 is forced to be unsafe in the same way .ctor 3 is:

public BufferedThing(int bufferSize){}

[CallerMustBeUnsafe]
public BufferedThing(byte[] internalBuffer){}

public BufferedThing(byte* internalBuffer, int bufferLength){}

e.g.

var buffer0 = new BufferedThing(10); // fine

var buffer1 = new BufferedThing(new byte[10]); // compile error

unsafe {
    var buffer2 = new BufferedThing(new byte[10]); // fine
}

unsafe {
    var buffer = new byte[10];
    fixed (byte* pBuffer = &buffer[0]) {
        var buffer3 = new BufferedThing(pBuffer, 10); // fine
    }
}

[morganbr]

I like this for a couple reasons:

1. It can be a compile-time check with no runtime overhead (though that means you'd need to re-file this in https://github.com/dotnet/roslyn) -- this is especially important for runtimes like .NET Native and CoreRT that don't implement transparent/critical code.
2. It makes it clear that even if you're not directly using pointers, what you're doing isn't safe.
3. By default, all code is critical, so calling critical methods doesn't necessary attract special attention.

A real-world example of this would be methods on the Marshal class such as Copy and StructureToPtr.

[benaadams]

@morganbr refiled there if you want to add your comment? dotnet/roslyn#8663