default tcp host
ralf.habacker at freenet.de
Thu Jun 21 00:16:37 PDT 2007
Daniel P. Berrange schrieb:
> On Wed, Jun 20, 2007 at 12:46:00PM -0400, Havoc Pennington wrote:
>> DBusString is preferred to any manual string manipulation, basically
>> char* is only used for "immutable-ish" strings (precision guidelines r
>> us!). The codebase avoids most of string.h to minimize that category of
>> security (and crash) bugs. (For read-only use, you can quickly init a
>> DBusString with an existing char* with _dbus_string_init_const())
> The reason I used a pre-allocated char * is because that's what the
> getnameinfo() contract requires when resolving the port from a
> sockaddr_storage struct. So while I could pass in a DBusString to
> the method, I'll eventually need to use a pre-allocated char * for
> the impl.
>> Since listen_tcp_socket / connect_tcp_socket are fairly complex now, it
>> may be worth thinking about how some of the logic can be moved
>> cross-platform so it doesn't have to be synced to Windows, though feel
>> free to punt on that and we'll figure it out later. I don't want to do
>> it if it results in a big mess, and I can't really think of a good
>> non-big-mess way to deal with this. Once there is a Windows
>> implementation it might be easier to see how much of it is common to the
> I was looking at the existing Windows impl of the listen/connect methods
> and they in fact seem to have two completely separate implementations of
> each method toggled on #ifdef ENABLE_DBUSSOCKET which AFAICT is never
> enabled in the codebase.
We had just disabled the DBusSocket code but leaved it in the source for
Only the code where ENABLE_DUSSOCKET is not defined is relevant.
> Windows has getaddrinfo/getnameinfo, so it ought to be possible to have
> an almost 100% unified impl, with just a few inline #ifdef's to deal
> with way Windows handles errno with its sockets code.
not to forget the EWOULDSOCKET return code from recv() when using non
blocking sockets, which need special handling.
> That all said I have zero Windows machines, so while I can provide some code as a
> staring point, I'm unable to compile/debug Windows.
We have windows machines for compiling/debugging which makes it able to
fix compile errors. Debugging will be possible too with some assistance
from the dbus experts.
More information about the dbus