[announce] dbus4win

[Marc Mutz]

Hi Tor,

Your reply disappointed me, but I'm sure that's just because we misunderstood 
each other. Let's see whether we can clear this up :)

On Wednesday April 22 2009, Tor Lillqvist wrote:
> > Tor, I would really appreciate if you could continue, please.

This is my main request
(and Havoc's, in http://bugs.freedesktop.org/show_bug.cgi?id=16788#c1,
and Colin's in http://bugs.freedesktop.org/show_bug.cgi?id=16788#c4):

Break up the patch into manageable chunks.

I'm sorry it's been less visible than it could have been. Now, if for whatever 
reason you can't break up those changes yourself, git-wise, then the 
fall-back I had in mind was that I could do the actual breakup for you (I 
already started), but for that I'd need more information, which led me to 
request the following:

> > At least 
> > write some kind of changelog so I can see the trees in the remaining
> > forest (German saying).
>
> Hah, do you think I remember much of it as a whole any more? But
> please do feel free to ask specific question about details.

If you could please have a look over the commits in the patch-16788 branch at
  http://repo.or.cz/w/dbus4win.git?a=shortlog;h=refs/heads/patch-16788
and see whether they're complete, and if not, fix them, or drop me a note, 
and - probably more importantly - go over the HEAD commit of that branch 
(which contains the rest of your patch, but with the function order left 
intact for better diffs) and go over the hunks in the *.c files, assign them 
to threads of related changes and write a short note about what you wanted to 
achieve with each such set of related changes. Extra points for specifying 
dependencies between them.

I am sure your memory will return when you see the very readable diff (which 
could be improved further by removing whitespace-only changes). :) I've 
attached it to this mail.

Please note that it's still your patch, and that you are the most qualified 
person to make sense of it :)

> > Esp the error handling changes are all over the place.
>
> What error handling changes? You mean saving the errno value from
> where the error you want to report happened to where you later check
> it? If some C library calls or system calls that might overwrite errno
> are done inbetween? Like this:
>
> @@ -918,8 +923,9 @@ _dbus_listen_tcp_socket (const char     *host,
>
>        if (bind (fd, (struct sockaddr*) tmp->ai_addr, tmp->ai_addrlen) < 0)
>          {
> +          saved_errno = errno;
>            _dbus_close(fd, NULL);
> -          if (errno == EADDRINUSE)
> +          if (saved_errno == EADDRINUSE)
>              {
>                /* Depending on kernel policy, it may or may not

No, this is already in FD.org master.

> Or do you mean the removal of the huge case statements that turn error
> codes WSAE* or NERR_* into strings? Such code is so unnecessary, the
> system already has a mechanism (FormatMessage()) for getting the error
> strings for such error codes.

I guess I've gotten to the bottom of the error handling changes now, but I was 
wondering, e.g., why there was a constant return from 
_dbus_error_from_wsaerror()? 

Thanks,
Marc

-- 
Marc Mutz <marc at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions