On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current
implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
buf[0] = 0xFF;
}
void main() @safe
{
auto buffer = new Object[1];
readData(buffer);
}
There are (at least) two major problems here:
1) Casting an array of elements with indirections (in this
case
Object[]) to void[] is questionable at best, outright unsafe
at worst,
as shown here. Even if we were to rewrite readData() and mark
it
@trusted, it still raises the question of what a @trusted
function can
legally do with void[], which is essentially a type-erased
array, that
justifies being tagged as @trusted. How can a function do
anything that
doesn't break @safety if all type information about the array
has been
erased, and it essentially sees it only as a ubyte[]? I'm
inclined to
say that @trusted functions should only be allowed to receive
const(void)[] as parameter, not void[].
https://issues.dlang.org/show_bug.cgi?id=15702
No problem here. There is no way to assign to a void[] without
doing 2.
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[] = arr2[0 .. arr.length];
}
Well, I'm not sure that that's actually not @safe. It's trying to
interpret the void[] that's the problem. Certainly, you can
convert T[] to void[] and pass it around all day without risking
any memory corruption, so that should definitely be @safe, and I
don't see how reducing the length of a void[] could actually
cause memory corruption on its own. It's when you cast the void[]
to something else that you risk things going south, and that's
what needs to be @system. So, I'm not sure that there's actually
any reason for your example code to not be @safe.
- Jonathan M Davis
