[haiku-commits] Re: haiku: hrev43302 - src/kits/network/libnetapi headers/os/net

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 22 Nov 2011 00:19:51 +0100

On 11/22/2011 12:03 AM, Alex Wilson wrote:
+static SSL sSSL;
I assume the goal of sSSL is to have the SSL lib automagically init
for clients? I don't think this is the best way to do it, since this
could potentially be a slow operation, and not everyone using
libnetapi will be using SSL. Furthermore, if someone writes code with
a static object that assumes ssl is initialized, then their code could
break, depending on the static initialization order. A lazy
initialized static class member is a better option, I think. This
allows for idempotent, only-on-demand loading, and solves the static
initialization order issue.

Yes, indeed, you're right.

Having client code (SecureSocket, for instance) call a method like
BPrivate::SSL::Init() is also more self-documenting, removing a bit of
magic for others who might want to hack on this code.

Good point, too.

+BSecureSocket::BSecureSocket(const BSecureSocket&  other)
+       :
+       BSocket(other)
+{
+       // TODO: this won't work this way!
+       fPrivate = 
(BSecureSocket::Private*)malloc(sizeof(BSecureSocket::Private));
+       if (fPrivate != NULL)
+               memcpy(fPrivate, other.fPrivate, 
sizeof(BSecureSocket::Private));
+       else
+               fInitStatus = B_NO_MEMORY;
+}
This isn't a great TODO, although I realize you're likely to be the
one that solves it, it doesn't always happen that way, so our TODO's
should be verbose enough that anyone coming across it will have a good
idea of what needs to be done.

I haven't looked into what needs to be done; it's just clear that this won't work, as the two objects will share the same SSL objects.

I also wondered while looking at this code why you're not using
new(std::nothrow) with a copy constructor to make a copy of
other.fPrivate. Maybe using malloc instead of new relates to your
TODO, I'm not sure...

Damn, good and simple idea, indeed, but not related to the TODO. I guess I still have some C written on my forehead after all these years :-) I'll put this on my TODO list, but it'll be some time until I find the time to actually work on that. Feel free to fix it for me inbetween.

Anyway, this is a cool addition. Is the goal to one day apply this to
Web+ to help getting away from Curl, or is this targeted towards Mail?

I'm still working on getting IMAP to work properly. Even though I am very low on time these days, I obviously decided to do it somewhat right, which unfortunately requires quite a lot of changes, as the current state is pretty much useless.

Bye,
   Axel.

Other related posts: