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 course! I certainly wouldn't mind seeing a c
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 Fri, 30 Oct 2009, John Engelhart wrote:
I'd suggest adding to the documentation an example work loop geared towards
"long running applications", such as one where a background thread is ticked
off to just process ares_* stuff.
If you write up an example, I'm sure we can fit it somewhere.
Hey,
struct ares_txt_reply {
unsigned int length;
unsigned char *txt;
};
I would really like to change the 'length' data type to 'unsigned
long', or even more properly to 'size_t'. We can not be defensive
enough about what an evil DNS server might send back.
--
-=[Yang]=-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2009 11:55 AM, Daniel Stenberg wrote:
> 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 functi
