Issue 15702: std.socket.Socket.receive can be @trusted only if buffer has no indirections #4011
Conversation
… has no indirections. Anything that receives void[] and writes to it cannot be considered @trusted, because passing in an array of element with indirections will cause overwriting of pointers with arbitrary network data.
|
Basically every I/O API, present and future, has this issue. I'd rather we make one small change to the language than complicating a crapload of library APIs. |
|
And what would that language change be? |
|
This would break my SSL socket because it depends on receive being virtual. It would be better to keep void[] and just fix the language so types with indirections are not implicitly casted when you are calling a |
|
@adamdruppe Hmm, you're right, I hadn't thought of class inheritance. :-( Looks like what's really needed here is a compiler fix. I'll look into that. |
You've already read it at least once. This would also break Dirk's SSL socket for the same reason it would break @adamdruppe's - it overrides |
|
Makes sense. Looking into the compiler code right now. So basically we'll allow implicit conversion of |
Anything that receives
void[]and writes to it cannot be considered@trusted, because passing in an array of element with indirections to, say,std.socket.Socket.receivewill cause overwriting of pointers with arbitrary network data.So rework the API not to throw away type information about the incoming array until we have checked whether it contains indirections. In order not to break code that needs to call
receiveon arrays with indirections, we still allow the call but it will be@systeminstead of@trusted. E.g., a multithreaded program that uses sockets to communicate between threads may be able to legitimately pass pointers via sockets. But since we cannot guarantee@safe-ty in this case, such calls toreceivewill be@system, and it's up to the user to verify that things work correctly and mark their own code as@trustedwhere applicable.