default tcp host
Daniel P. Berrange
dan at berrange.com
Wed Jun 20 04:27:22 PDT 2007
On Wed, Jun 20, 2007 at 12:46:00PM -0400, Havoc Pennington wrote:
> Awesome, some mostly style-type comments inline, I think the basic
> approach should work fine
> Daniel P. Berrange wrote:
> >+#define MAX_SOCKET 10
> Just sucking it up and dynamically sizing this array probably makes
> sense - it never resizes, the nfd is passed in at construct-time, so
> it's just as easy.
Ok, will do.
[snip other coding style issues]
> >+ else if (!strcmp(bind, "*"))
> The convention in libdbus is == 0 rather than !
Will fix all these style issues.
> >+ * @param retfd location to store returned file descriptors
> >+ * @param nretfd maximum number of returnable file descriptors
> Rather than create this limitation / burden on the caller, just do it like:
> int **fds_p,
> int *n_fds_p
> and return an allocated array.
> Similarly for the returned port, though in that case you can have the
> caller pass in an initialized DBusString to be modified, instead of
> manually returning a char*
> >+ strncpy(retport, port, retportlen-1);
> >+ retport[retportlen-1] = '\0';
> 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
> 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.
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. 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.
|=- GPG key: http://www.berrange.com/~dan/gpgkey.txt -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- berrange at redhat.com - Daniel Berrange - dan at berrange.com -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070620/5ee8f084/attachment.pgp
More information about the dbus