Yet another leak in the sinking ship of @safe

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 18, 2016 at 01:58:24PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
> >While @safe is a good idea in principle, the current implementation
> >is rather lackluster.
> 
> IMO, I think safe code should disallow casting that doesn't involve a
> runtime function that verifies safety (such as casting an object to
> another type, or invoking a @safe opCast), including casting array
> types.

But isn't casting from, say, long[] to int[] @safe? Last time I checked,
druntime does actually convert .length correctly as well, so that
converting, say, int[] to long[] won't let you overrun the array by
accessing the last elements of the long[].

But obviously casting Object[] to long[] would be a very bad idea, and
should not be allowed in @safe. Scarily enough, this code currently
compiles without any complaint from the compiler:

	void main() @safe
	{
		Object[] objs = [ new Object() ];
		long[] longs = cast(long[]) objs;
		longs[0] = 12345;
	}

Yikes. Apparently you don't even need void[] to break @safe here. :-(


> And implicit casts to void[] should be disallowed.
> 
> This would be a painful restriction, which is why I think it won't
> happen :(
[...]

As far as I can tell, implicit casting to const(void)[] shouldn't be a
cause for concern -- if all you can do with it is to read the data
(e.g., a hexdump debugging function for printing out the byte
representation of something), there shouldn't be any problems. It's when
you write to the void[] that bad things begin to happen.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.