Thank you so much, David!
On Thu, Feb 4, 2016 at 5:44 AM, David Drysdale wrote:
> OK, I've added that change to the repo (and put in a quick test case for
> it).
>
> The Travis builds are running, but be warned: the coverage-generation
> build may well fail because coveralls.io is flaky at the m
OK, I've added that change to the repo (and put in a quick test case for
it).
The Travis builds are running, but be warned: the coverage-generation build
may well fail because coveralls.io is flaky at the moment.
D.
On Wed, Feb 3, 2016 at 8:03 PM, Fedor Indutny wrote:
> My bad, didn't run the
My bad, didn't run the code indeed. All fixed, code tested in:
https://github.com/nodejs/node/pull/5062
https://ci.nodejs.org/job/node-test-commit/2081/
Appears to be working just fine with node.js .
Updated patch in attachment.
Sorry about typos!
Thank you,
Fedor.
On Wed, Feb 3, 2016 at 10:4
Thank you, Daniel.
Hopefully, I have fixed all mentioned nits. I tried to do my best on the
documentation, but please forgive me some grammar issues since I am not a
native english speaker.
If you have any other suggestions with regards to either code, docs, or
both. I will be more than happy to
On Mon, 1 Feb 2016, Fedor Indutny wrote:
I have made fixes to the patch from 2015-03-21, according to your comments.
Please take a look.
Two comments from me:
1. Please don't refer to source code file names in ares.h. That's a public
header file and users of c-ares will read that and have n
Hello David,
I have made fixes to the patch from 2015-03-21, according to your comments.
Please take a look.
Thank you!
On Mon, Feb 1, 2016 at 11:12 AM, David Drysdale wrote:
> The first version of the patch still has the problem that it changes the
> size of
> an existing structure and thus
No worries at all!
Does the first version of patch look better now?
Thank you,
Fedor.
On Thu, Jan 28, 2016 at 5:05 PM, Daniel Stenberg wrote:
> On Thu, 28 Jan 2016, Fedor Indutny wrote:
>
> Just FYI, this `age` thing was actually suggested by you earlier in this
>> thread, but I will be more t
On Thu, 28 Jan 2016, Fedor Indutny wrote:
Just FYI, this `age` thing was actually suggested by you earlier in this
thread, but I will be more than happy to remove it.
I know, and I'm sorry I lead you down that path! :-(
--
/ daniel.haxx.se
In fact, this is what we have happily used in node.js for [quite a long
time][0]
[0]:
https://github.com/nodejs/node/commit/a60a9b0dbd064cd70de9400ad47421c19d29b021
On Thu, Jan 28, 2016 at 4:35 PM, Fedor Indutny wrote:
> Hello Daniel, David,
>
> Just FYI, this `age` thing was actually suggested
Hello Daniel, David,
Just FYI, this `age` thing was actually suggested by you earlier in this
thread, but I will be more than happy to remove it. May I ask you if the
very first patch in this thread makes more sense now?
Attached it just in case. If it looks better - I will amend man page with
re
On Thu, 28 Jan 2016, David Drysdale wrote:
Personally, I'd lean towards not including the age / reserved extension
mechanism. None of the other structures that describe particular resource
records have it, and the first/rest marker is just an accidental omission
from the TXT structure, so jus
Kindly reminding you about this.
On Wed, May 27, 2015 at 3:24 PM, Fedor Indutny wrote:
> Ping? ;)
>
> On Mon, Apr 6, 2015 at 11:41 PM, Fedor Indutny wrote:
>
>> Ping ;)
>>
>> On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny wrote:
>>
>>> Hello guys!
>>>
>>> Long time again :) Sorry, I was busy w
Ping? ;)
On Mon, Apr 6, 2015 at 11:41 PM, Fedor Indutny wrote:
> Ping ;)
>
> On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny wrote:
>
>> Hello guys!
>>
>> Long time again :) Sorry, I was busy with various other stuff.
>>
>> Here is a patch with (hopefully) all suggested changes.
>>
>> Please tak
Ping ;)
On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny wrote:
> Hello guys!
>
> Long time again :) Sorry, I was busy with various other stuff.
>
> Here is a patch with (hopefully) all suggested changes.
>
> Please take a look!
>
> Thank you,
> Fedor.
>
> On Thu, Dec 11, 2014 at 5:05 AM, Jakub Hr
Hello guys!
Long time again :) Sorry, I was busy with various other stuff.
Here is a patch with (hopefully) all suggested changes.
Please take a look!
Thank you,
Fedor.
On Thu, Dec 11, 2014 at 5:05 AM, Jakub Hrozek wrote:
> On Thu, Dec 11, 2014 at 09:54:47AM +0100, Daniel Stenberg wrote:
> >
On Thu, Dec 11, 2014 at 09:54:47AM +0100, Daniel Stenberg wrote:
> On Thu, 11 Dec 2014, Jakub Hrozek wrote:
>
> >>You want me to add a couple of `void*`?
> >
> >I was thinking:
> > uint8_t reserved[16];
>
> Another way, which is one I've used elsewhere, is this:
>
> struct larger_in_future {
On Thu, 11 Dec 2014, Jakub Hrozek wrote:
You want me to add a couple of `void*`?
I was thinking:
uint8_t reserved[16];
Another way, which is one I've used elsewhere, is this:
struct larger_in_future {
int age; /* generation of struct */
void *member; /* always present */
On Thu, Dec 11, 2014 at 09:00:28AM +0700, Fedor Indutny wrote:
> You want me to add a couple of `void*`?
I was thinking:
uint8_t reserved[16];
or similar.
I pulled the number out of thin air completely.
You want me to add a couple of `void*`?
On Thu, Dec 11, 2014 at 6:10 AM, Daniel Stenberg wrote:
> On Wed, 10 Dec 2014, Fedor Indutny wrote:
>
> The only thing that is missing is an extra field.
>>
>
> What about coming up with a way to make the struct possible to change in
> the future so that
On Wed, 10 Dec 2014, Fedor Indutny wrote:
The only thing that is missing is an extra field.
What about coming up with a way to make the struct possible to change in the
future so that we won't have to create yet another function later down the
line?
--
/ daniel.haxx.se
Jakub,
In the more recent patch, I'm returning the new structure as you have just
said.
The only thing that is missing is an extra field.
Cheers,
Fedor.
On Wed, Dec 10, 2014 at 11:21 PM, Jakub Hrozek wrote:
> On Wed, Dec 10, 2014 at 03:12:16PM +0700, Fedor Indutny wrote:
> > Daniel,
> >
> > I
On Wed, Dec 10, 2014 at 03:12:16PM +0700, Fedor Indutny wrote:
> Daniel,
>
> I had a strange de-ja-vu about it, and I was right. I already did one patch
> like that in past.
>
> Anyway, I redid it - so including both old and new versions for your
> reviewal.
>
> Thank you,
> Fedor.
As a strange
Daniel,
I had a strange de-ja-vu about it, and I was right. I already did one patch
like that in past.
Anyway, I redid it - so including both old and new versions for your
reviewal.
Thank you,
Fedor.
On Wed, Dec 10, 2014 at 12:28 PM, Fedor Indutny wrote:
> Ok, sounds like a plan.
>
> On Wed,
Ok, sounds like a plan.
On Wed, Dec 10, 2014 at 6:28 AM, Daniel Stenberg wrote:
> On Fri, 5 Dec 2014, Fedor Indutny wrote:
>
> We kind of did, but never decided on a way of doing it. Do you have any
>> suggestions?
>>
>
> We need a new function that returns another struct so that the existing
>
On Fri, 5 Dec 2014, Fedor Indutny wrote:
We kind of did, but never decided on a way of doing it. Do you have any
suggestions?
We need a new function that returns another struct so that the existing
applications remain functional and new ones can use the new shiny.
--
/ daniel.haxx.se
Daniel,
We kind of did, but never decided on a way of doing it. Do you have any
suggestions?
Cheers,
Fedor.
On Fri, Dec 5, 2014 at 1:54 AM, Daniel Stenberg wrote:
> On Fri, 5 Dec 2014, Fedor Indutny wrote:
>
> The patch was in the first email from this thread.
>>
>
> Yes, like almost 200 year
On Fri, 5 Dec 2014, Fedor Indutny wrote:
The patch was in the first email from this thread.
Yes, like almost 200 years ago =)
Let me re-paste it here just in case.
Thanks! Didn't we already agree that we cannot modify the public struct like
that as it risks break existing users of that ca
Hello Daniel!
The patch was in the first email from this thread. Let me re-paste it here
just in case.
Regarding node.js - yeah, users asked us to fix the TXT replies and we
waited for c-ares upstream to land the patch, but since it didn't happen -
we floated the patch on our own. I don't say tha
On Thu, 4 Dec 2014, Fedor Indutny wrote:
I still would like to ask you to land this in the form it has right now.
You'd simplify our lives if you'd also attach the patch you're talking about,
or a link to it!
This has already caused some problems with incompatibility between c-ares in
node
I still would like to ask you to land this in the form it has right now.
This has already caused some problems with incompatibility between c-ares
in node.js and the distributed shared library.
Please let me know how I could help you proceeding with this.
Thank you,
Fedor.
On Thu, Jun 12, 2014
I think it applies to each record, otherwise it would indeed just an
additional `int*` argument.
Any ideas? Perhaps we could land it in a way it is right now?
On Wed, Jun 11, 2014 at 2:40 AM, Saúl Ibarra Corretgé
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/06/2014 06:30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/06/2014 06:30 AM, Fedor Indutny wrote:
> Thinking about it, I have only one hacky idea for implementing it
> without bloating the code base, or allocating excessive bytes.
>
> The TTL could be put into the `len` field of record when `txt` is
>
Thinking about it, I have only one hacky idea for implementing it without
bloating the code base, or allocating excessive bytes.
The TTL could be put into the `len` field of record when `txt` is `NULL`.
Does it seems good to you guys?
On Wed, May 28, 2014 at 6:12 PM, Fedor Indutny wrote:
> Oh
Oh right, will do it.
On Wed, May 28, 2014 at 4:59 PM, Saúl Ibarra Corretgé wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/27/2014 12:01 PM, Fedor Indutny wrote:
> > Sure, here are attached changes.
> >
> > Please let me know if I should improve them even further.
> >
>
> Loo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/27/2014 12:01 PM, Fedor Indutny wrote:
> Sure, here are attached changes.
>
> Please let me know if I should improve them even further.
>
Looks good to me, FWIW.
Someone asked if you could add the TTL data there, maybe taking the
same approac
Sure, here are attached changes.
Please let me know if I should improve them even further.
On Tue, May 27, 2014 at 12:39 PM, Jakub Hrozek wrote:
> On Tue, May 27, 2014 at 12:53:41AM +0400, Fedor Indutny wrote:
> > Agreed, will look into implementing it.
>
> Would you consider also adding TTL w
On Tue, May 27, 2014 at 12:53:41AM +0400, Fedor Indutny wrote:
> Agreed, will look into implementing it.
Would you consider also adding TTL when creating this "ares_parse_txt2"
?
>
>
> On Tue, May 27, 2014 at 12:50 AM, Daniel Stenberg wrote:
>
> > On Thu, 22 May 2014, Fedor Indutny wrote:
> >
Agreed, will look into implementing it.
On Tue, May 27, 2014 at 12:50 AM, Daniel Stenberg wrote:
> On Thu, 22 May 2014, Fedor Indutny wrote:
>
> Unfortunately, there is no certain description of how TXT records should
>> be used after parsing. Clearly some people may want to get each chunk of
On Thu, 22 May 2014, Fedor Indutny wrote:
Unfortunately, there is no certain description of how TXT records should be
used after parsing. Clearly some people may want to get each chunk of each
record separately and use them as they want to. Concatenation will
definitely make c-ares unusable fo
Hello Saul!
As an alternative, I could use `NULL` txt field to indicate a record
separation, but this
will break the existing code.
Unfortunately, there is no certain description of how TXT records should be
used after
parsing. Clearly some people may want to get each chunk of each record
separat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2014 09:19 PM, Fedor Indutny wrote:
> Introduce `record_start` field, indicating start of new TXT record,
> thus allowing to differentiate chunks in the same record, from a
> chunks in a different record.
Hey Fedor!
This patch changes the AB
Hi Jakub,
2009/11/22, Jakub Hrozek wrote:
>
> See attached patch prefix-structures-with-ares.patch
>
> [...]
>
> OK, I saw you did some changes already, so I hope I won't be stepping on
> your toe with this, but see the attached
> sync-man-pages-with-prototypes.patch patch.
>
> Hope this helps,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2009 02:54 AM, Yang Tse wrote:
> 1)
>
> In ares.h there's a comment mentioning that a couple of structs should
> be renamed to avoid name space pollution, prefixing ares_ to them.
> Obviously the change should be reflected elsewhere, code and
Jakub and all,
ares_parse_srv_reply() and ares_parse_txt_reply() updated in CVS with
your API changes and also to make use of the new ares_free_data().
No man page yet for ares_free_data(), but comments in ares_data.c and
ares_data.h should give you nearly all the info that there will be in
the m
2009/11/20, Jakub Hrozek wrote:
> is there anything I can help with, either with the generic
> free or just polishing the next release in general?
>From the general part I'm aware at least of two points right away.
1)
In ares.h there's a comment mentioning that a couple of structs should
be ren
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/2009 05:08 PM, Yang Tse wrote:
> Jakub,
>
> I haven't forgotten you. Its simply I'm very short of time. You're the
> next on my list.
>
> Cheers,
Thank you, Yang. I really appreciate it!
Just to shed some light on why I am hoping for a new
Jakub,
I haven't forgotten you. Its simply I'm very short of time. You're the
next on my list.
Cheers,
--
-=[Yang]=-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/02/2009 07:59 PM, Yang Tse wrote:
> Hmm, I've started writing a theoretical comparison of both approaches,
> but I've deleted it all. Tomorrow most probably.I'm going to code my
> version, and afterwards I'll comment.
Hi,
is there anything I ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/02/2009 07:59 PM, Yang Tse wrote:
> It is obvious that the difference is directly storing an
> ares_[txt|srv]_reply struct in the 'ares private internal struct' or
> storing a pointer to a dynamically allocated ares_[txt|srv]_reply
> struct.
>
2009/11/2, Jakub Hrozek wrote:
> A patch is attached. I did factor in some of Yang's suggestions but so
> far it only works for SRV and TXT parsing routines..I'm not sure if what
> he posted (although a good plan!) is plan for the upcoming release or
> the next one and I did not want to touch exis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/31/2009 11:33 PM, Daniel Stenberg wrote:
> On Fri, 30 Oct 2009, Jakub Hrozek wrote:
>
>> So, what about a slight change in the external structures:
>>
>> struct ares_srv_reply {
>>
>> struct ares_srv-reply *next;
>> }
>>
>> and have the pri
Some additional brainstormin on the generic ares free function...
Would it be ok that the purpose of a c-ares external API
ares_freedata() function is to allow the calling application to free
memory resources that have been internally allocated by some c-ares
function and for which a pointer has a
On Fri, 30 Oct 2009, Jakub Hrozek wrote:
So, what about a slight change in the external structures:
struct ares_srv_reply {
struct ares_srv-reply *next;
}
and have the private structure defined along the lines:
struct ares_private {
int magic;
union {
struct ares_srv_reply sr
-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
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 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, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/27/2009 07:26 PM, Daniel Stenberg wrote:
> I gave it a quick glance just now and I spotted two things:
>
> 1) 'struct txt_reply' is a global struct and should thus be with ares_
> prefix
>like ares_txt_reply or similar.
>
Renamed. I should
On Tue, 27 Oct 2009, Jakub Hrozek wrote:
I tested that apart from simple records and multiple records per host, it
also handles multiple substrings in the TXT record (used to make the whole
string>255 bytes, configured as 'host IN TXT ( "Foo" "Bar" )' in Bind).
Comments or reviews are mostly
66 matches
Mail list logo
