Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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: [PATCH] ares_parse_txt_reply: add `record_start` field

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: >> >>>

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

Ping? ;) On Mon, Apr 6, 2015 at 11:41 PM, Fedor Indutny fe...@indutny.com wrote: Ping ;) On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny fe...@indutny.com wrote: Hello guys! Long time again :) Sorry, I was busy with various other stuff. Here is a patch with (hopefully) all suggested

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

Ping ;) On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny fe...@indutny.com 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,

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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 jhro...@redhat.com wrote: On Thu, Dec 11, 2014 at 09:54:47AM +0100, Daniel

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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 { int age;

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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 fe...@indutny.com wrote: Ok, sounds like a

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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 dan...@haxx.se wrote: On Fri, 5 Dec 2014, Fedor Indutny wrote: The patch was in the first email from this thread. Yes, like almost

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

-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 approach

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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 dan...@haxx.se wrote: On Thu, 22 May 2014, Fedor Indutny

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

. -- / daniel.haxx.se -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - From 2dd4eec675ccc605cc88cc2099b109c2db05e128 Mon Sep 17 00:00:00 2001 From: Fedor Indutny fe...@indutny.com Date: Fri, 28 Mar 2014 00:14:59 +0400 Subject: [PATCH] ares_parse_txt_reply: ares_parse_chunked_txt_reply

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

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

Re: [PATCH] ares_parse_txt_reply: add `record_start` field

Agreed, will look into implementing it. On Tue, May 27, 2014 at 12:50 AM, Daniel Stenberg dan...@haxx.se 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

[PATCH] ares_parse_txt_reply: add `record_start` field

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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAABAgAGBQJTNIorAAoJEPsOEJWxeXmZTDAP/0BVAUgror62mPtpTb/VlO+o

Re: [PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

-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

Re: [PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

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

Re: [PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

Jakub, I haven't forgotten you. Its simply I'm very short of time. You're the next on my list. Cheers, -- -=[Yang]=-

[PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

-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 { data struct ares_srv-reply *next; } and have the private

Re: [PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

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

Re: [PATCH] ares_free_reply (Was: Re: [PATCH] ares_parse_txt_reply)

-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. Just

Re: [PATCH] ares_parse_txt_reply

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

Re: [PATCH] ares_parse_txt_reply

On Fri, 30 Oct 2009, Jakub Hrozek wrote: So, what about a slight change in the external structures: struct ares_srv_reply { data struct ares_srv-reply *next; } and have the private structure defined along the lines: struct ares_private { int magic; union { struct

Re: [PATCH] ares_parse_txt_reply

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]=-

Re: [PATCH] ares_parse_txt_reply

-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 function and

Re: [PATCH] ares_parse_txt_reply

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

Re: [PATCH] ares_parse_txt_reply

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

Re: [PATCH] ares_parse_txt_reply

-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 along

Re: [PATCH] ares_parse_txt_reply

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

Re: [PATCH] ares_parse_txt_reply

-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 anything

Re: [PATCH] ares_parse_txt_reply

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]=-

Re: [PATCH] ares_parse_txt_reply

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

Re: [PATCH] ares_parse_txt_reply

-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?