Yet another leak in the sinking ship of @safe

[Jonathan M Davis via Digitalmars-d]

On Thursday, 18 February 2016 at 19:28:16 UTC, Kagamin wrote:
> On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
>> (*ahem*std.socket*cough*) liberally sprinkle @trusted on every 
>> function without regard to whether it's truly justified (e.g., 
>> see https://issues.dlang.org/show_bug.cgi?id=15672)
>
> How is bug 15672 related to std.socket? From quick glance at 
> first thousand lines of std.socket I don't see functions 
> incorrectly marked as trusted.

The problem with std.socket is that calls to stuff like recv 
involve processing the data from void[], which is inherently 
unsafe, but the D functions calling them (e.g. receive) are 
marked as @trusted. It's conceptually similar to 15672 in that 
recv is taking the void* that it's given (from the void[]) and 
essentially converting it to ubyte* (or char*, since it's C), 
which is more or less equivalent to casting the void[] to 
ubyte[], which is what 15672 is about. However, even if 15672 is 
fixed, it wouldn't affect std.socket any, because it's the fact 
that a pointer to void[] is passed to a C function that converts 
it to ubyte*/char* that's the problem, not that void[] is 
converted to ubyte[] (since that never actually happens).

- Jonathan M Davis