Hi Daniel,
That patch that you generated seems to have a problem, in that it
contains changes that I didn't make. Perhaps your source code base was
different than mine.
The only reason I didn't work off git and trunk was simply that a) I've
never used git before and frankly my task is busy enough without having
to learn a new tool (I'm on a strict deadline for this week), and b) I
needed to base my work of a stable release, which is why I chose the
link on the website for the snapshot, instead of trunk. I am making an
assumption that what is on the website is tested and stable, moreso than
trunk. Maybe that's wrong?
Anyway, once I've submitted everything into our own local working
repository I'll be happy to get it sorted out with you and get the
changes mainlined.
Let me go through the motions on my end and then I'll try to clean it up
and give you a nice patch to look at based on git (if I can figure that
out).
On 11-05-15 06:39 PM, Daniel Stenberg wrote:
> On Fri, 13 May 2011, David Stuart wrote:
>
>> Here's a 7zip file containing the changed files for my patch
>
> Please send us (unified) patches for changes as made with diff -u or
> plain git. Complete replacement files are inconvenient. I've attached
> the patch to this mail, generated from your files compared to what's in
> git right now.
>
> Then we will also ask you to provide separate patches for separate
> changes so that we can see exactly what you need to change to fix this
> specific problem.
>
> There might be other things to fix and change as well, but they must be
> provided in separate patches.
>
>> using the 1.7.4 file on the website as the base.
>
> Did you try using a daily snapshot of something more recent?
>
>> Maybe someone could have a look at it?
>
> I know nothing about the Windows specifics so I can't comment on those.
> I assume regular old IPv4 and IPv6+IPv4 setups still work fine even with
> your improvements?
>
> The fact that you've modified an older version does make the patch
> flawed though, as it removes things we've added during the last few
> months. That's wrong. (My fault though for using the wrong version to
> generate the diff from.)
>
> Can you explain the reasoning by the change of try_config() ? To me it
> looks like you've simply removed existing logic. It also seems
> irrelevant to your windows improvements.
>
> Your edits of advance_tcp_send_queue() is very hard to read since you
> re-indented the function making just about the entire function modified
> but most of the logic is ther same... The reindent seems irrelevant.
>
> I assume you changed the struct field named 'try' to 'try_count' for
> some weird compiler thinking it was a C++ compiler? Was this really a
> relevant change?
>
>> I'm also wondering whether I need to filter out some of the link local
>> multicast/broadcast IPv6 addresses that seem to be returned in the DNS
>> server list for Windows.
>
> Hm, what will be the effect if you don't?
>
-- David Stuart, CounterPath Email: dstuart (at) counterpath (dot) com Phone: (613) 254-8886 x2234 Web: http://www.counterpath.com/ Address: 310 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5Received on 2011-05-16