On Monday, 5 May 2014 at 10:41:41 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 10:24:27 +0000
via Digitalmars-d <[email protected]> wrote:
On Monday, 5 May 2014 at 09:32:40 UTC, JR wrote:
> On Sunday, 4 May 2014 at 21:18:24 UTC, Daniele M. wrote:
>> And then comes my next question: except for that
>> malloc-hack,
>> would it have been possible to write it in @safe D? I guess
>> that if not, module(s) could have been made un-@safe. Not
>> saying that a similar separation of concerns was not
>> possible
>> in OpenSSL itself, but that D could have made it less
>> development-expensive in my opinion.
>
> TDPL SafeD visions notwithstanding, @safe is very very
> limiting.
>
> I/O is forbidden so simple Hello Worlds are right out, let
> alone advanced socket libraries.
I/O is not forbidden, it's just that writeln and friends
currently can't be made safe, but that is being worked on
AFAIK.
While I/O usually goes through the OS, the system calls can be
manually verified and made @trusted.
As the underlying OS calls are all C functions, there will
always be @system
code involved in I/O, but in most cases, we should be able to
wrap those
functions in D functions which are @trusted.
Regarldess, I would think that SSL could be implemented without
sockets - that
is, all of its operations should be able to operate on
arbitrary data
regardless of whether that data is sent over a socket or not.
And if that's
the case, then even if the socket operations themselves had to
be @system,
then everything else should still be able to be @safe.
Most of the problems with @safe stem either from library
functions that don't
use it like they should, or because the compiler does not yet
do a good enough
job with attribute inference on templated functions. Both
problems are being
addressed, so the situation will improve over time. Regardless,
there's
nothing fundamentally limited about @safe except for operations
which are
actually unsafe with regards to memory, and any case where
something isn't
@safe when it's actually memory safe should be and will be
fixed (as well as
any situation which isn't memory safe but is considered @safe
anyway - we do
unfortunately still have a few of those).
- Jonathan M Davis
You nailed it. If we wanted to translate the theoretical exercise
into something real, it would be nice to have an implementation
of PolarSSL that works on ring buffers only, then leave network
layer integration to clients. Much cleaner separation of concerns.
