[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:
