-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2009 10:30 PM, Daniel Stenberg wrote:
> On Thu, 29 Oct 2009, Yang Tse wrote:
>
>> Just a heads-up on this issue, CVS c-ares fails to compile for more
>> than twelve hours now. Are there any plans to fix/revert this before
>> daily snapshot?
>
2009/10/29, Daniel Stenberg wrote:
> That's related to the free function subject, as the ares_parse_txt_reply()
> hasn't been added to CVS and thus the build fails (since
> ares_parse_txt_reply() uses it).
I know. I've seen it. and after reading the thread was aware that it
was work in progress a
On Thu, 29 Oct 2009, Yang Tse wrote:
Just a heads-up on this issue, CVS c-ares fails to compile for more than
twelve hours now. Are there any plans to fix/revert this before daily
snapshot?
That's related to the free function subject, as the ares_parse_txt_reply()
hasn't been added to CVS an
Hi Daniel and Jakub,
Just a heads-up on this issue, CVS c-ares fails to compile for more
than twelve hours now. Are there any plans to fix/revert this before
daily snapshot?
Cheers,
--
-=[Yang]=-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2009 11:55 AM, Daniel Stenberg wrote:
> Right, those that return a "standard struct" we can't do much about. I
> really don't think we should add new APIs that return such structs but
> we can leave the exsisting as they are to not stir anythi
On Thu, Oct 29, 2009 at 02:15:11AM -0400, John Engelhart wrote:
> Fair enough. Could you elaborate a bit more on this? ares_timeouts() still
> uses a linear scan of the list, so is this function not in your critical
> path?
I'm afraid I don't know the details. I could try digging up the people wh
On Thu, 29 Oct 2009, Jakub Hrozek wrote:
All it would take is that we make sure we include a hint in the returned
data about what struct it is so that we can detect that in the free
function and then do the correct cleanup.
Well, from the point of view of the API user something along the line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> All it would take is that we make sure we include a hint in the returned
> data about what struct it is so that we can detect that in the free
> function and then do the correct cleanup.
>
Well, from the point of view of the API user something alon
On Wed, 28 Oct 2009, Jakub Hrozek wrote:
Yes, that is a bug. I think the best solution might be to provide a free
function and use it both internally in cases like this and provide it
externally.
Right, we have that problem with these functions allocating memory that is
returned so we need t
On Wed, 28 Oct 2009, Jakub Hrozek wrote:
Thank you for the review. A new patch is attached.
Thanks, applied and committed. I renamed the srv_reply struct too while I was
at it.
--
/ daniel.haxx.se
On Thu, 29 Oct 2009, John Engelhart wrote:
And, hypothetically speaking, if someone were to re-work the code, could you
provide feedback on whether or not the new code "works"?
Of course! I certainly wouldn't mind seeing a cleanup and improved time-out
code, and of course I'd review and test
On Wed, 28 Oct 2009, Jakub Hrozek wrote:
- From my very selfish POV, I'd like the c-ares-$NEXT to contain the SRV
(already in HEAD, but the concerns raised during the TXT patch review over
renaming global structures should happen before release) and TXT parsing
routines.
Right, since the SRV
12 matches
Mail list logo
