Jump to page: 1 2
Thread overview
[Issue 15702] std.socket.Socket.receive breaks @safe
Feb 18, 2016
Jonathan M Davis
Dec 17, 2022
Iain Buclaw
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|std.socket.Socket.receive   |std.socket.Socket.receive
                   |is breaks @safe             |breaks @safe

--
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |safe

--
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

--- Comment #1 from hsteoh@quickfur.ath.cx ---
This problem is made much worse by https://issues.dlang.org/show_bug.cgi?id=15672, because that allows the following truly evil code:

------
void readData(void[] buffer) @safe
{
        ubyte[] buf = cast(ubyte[]) buffer; // why does this compile?!
        buf[0] = 0xFF;
}
void main() @safe
{
        auto buffer = new Object[1];
        readData(buffer);
}
------

Thus, the @safe annotations here guarantee nothing at all.

--
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
I would think that converting from T[] to void[] would be @safe. That conversion won't actually corrupt anything. It's doing anything with the void[] which is the problem. Anything and everything which would involve interpreting what void[] is should definitely be @system.

--
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

--- Comment #3 from hsteoh@quickfur.ath.cx ---
Yes, I agree. Converting T[] to void[] is @safe, but doing basically anything with the void[] other than reading it must be @system. Which means std.socket.Socket.receive should be @system, not @trusted. At least, it cannot be @trusted unless it verifies via sig constraints that hasIndirections!T is false.

Unfortunately changing this will probably break existing code, and it ain't gonna be pretty.

--
February 18, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

--- Comment #4 from hsteoh@quickfur.ath.cx ---
Here's another example that shows why @safe/@trusted on any function that takes
(a non-const) void[] must be considered suspect (credit: Steven Schveighoffer,
from the forum thread):

----
void foo(void[] arr) @safe
{
    void[] arr2 = [123, 456, 789]; // this is clearly @safe
    arr[] = arr2[0 .. arr.length]; // so is this, under the current definition
}
----

--
February 19, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #5 from hsteoh@quickfur.ath.cx ---
https://github.com/D-Programming-Language/phobos/pull/4011

--
February 20, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

--- Comment #6 from hsteoh@quickfur.ath.cx ---
Changing std.socket.Socket.receive to use templates to check for array indirections will break too much code, and does not play nice with inheritance.

Proposed alternative solution is to make it illegal to implicitly convert T[] to void[] in @safe code if T has indirections. As a compromise, continue to allow explicit cast to void[]. This will plug this particular hole as well as highlight potentially dangerous implicit conversions to void[], but still continue to allow it if the user explicitly casts to void[]. Seems like a reasonable compromise.

--
February 20, 2016
https://issues.dlang.org/show_bug.cgi?id=15702

--- Comment #7 from hsteoh@quickfur.ath.cx ---
Alternative fix in the compiler:

https://github.com/D-Programming-Language/dmd/pull/5468

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=15702

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--
« First   ‹ Prev
1 2