Is there a reason why c-ares places 'configure / build' time in various
headers? For example, in ares_build.h there's CARES_SIZEOF_LONG.
The reason why I'm asking is I recently tried to build some code in 64-bit
mode and the compiler started kicking back stuff like:
Source/Headers/C-Ares/ares_ru
On Mon, Nov 2, 2009 at 4:18 PM, Daniel Stenberg wrote:
> On Mon, 2 Nov 2009, John Engelhart wrote:
>
> I'm wondering if the API could be expanded such that there were two calls:
>> one that provided the length of the buffer needed to hold the expanded
>> result, and
Hello,
I'm in the middle of writing an Objective-C wrapper around the base c-ares
library. There's a small tweak to the API that I'd like to request that
would make things a (tiny) bit better for my needs.
Since I'm providing high-level 'object' based 'parsed' results, I have a
need to call both
On Thu, Oct 29, 2009 at 4:32 AM, Daniel Stenberg wrote:
> Your 0+0 case is problematic only if it *repeatedly* returns 0 so that the
> program goes into a busy-loop and that is the problem: the repeated returns
> of "run now", not the "run now" when it happens only once. And repeated
> (unfounded
On Thu, Oct 29, 2009 at 4:32 AM, Daniel Stenberg wrote:
> 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 cours
On Wed, Oct 28, 2009 at 6:37 AM, Steinar H. Gunderson wrote:
>
> FWIW, if you're talking about the hash of doubly-linked lists, it was
> indeed
> added after profiling real-world performance problems here at Google. I
> don't
> know the specifics (I only forward-ported it from our internal reposit
On Tue, Oct 27, 2009 at 6:51 PM, Daniel Stenberg wrote:
> On Tue, 27 Oct 2009, John Engelhart wrote:
>
> On investigation I found that ares_timeout was returning a timeout of 0
>> seconds and 0 microseconds. The little digging I've done so far turned up
>> that ares_
On Tue, Oct 27, 2009 at 2:23 PM, Daniel Stenberg wrote:
> On Tue, 27 Oct 2009, Jakub Hrozek wrote:
>
> I know there had been a similar question asked by Daniel a couple of months
>> back, but since then, some other patches landed..so I wanted to ask again -
>> does c-ares upstream plan a new rele
I have the skeleton of an Objective-C wrapper for c-ares. Any interest in
seeing something like this added to the distribution?
On Mon, Oct 26, 2009 at 12:13 PM, Daniel Stenberg wrote:
> On Mon, 26 Oct 2009, Jakub Hrozek wrote:
>
> I'm aware that with srv_out == NULL you get a crash -- I'm still not sure
>> which way of coding is preferred within c-ares, be it the more defensive one
>> of ares_parse_{a,}_reply or the
While the top of ares_parse_srv_reply() checks the srv_out and nsrvreply
arguments to make sure they are non-NULL before using them, the bottom of
the function does not:
ares_parse_srv_reply(const unsigned char *abuf, int alen, struct srv_reply
**srv_out, int *nsrvreply)
{
// ... snip ... Near
(this is for the current source in CVS)
While doing some testing that happened to exercise ares_cancel, I noticed
that ares_strerror() was giving the following message for the canceled
queries:
Code=21 "c-ares library initialization not yet performed"
It seems that ares.h defines ARES_ECANCELLED
12 matches
Mail list logo
