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

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

From: Fedor Indutny <fedor_at_indutny.com>
Date: Mon, 6 Apr 2015 23:41:22 +0200

Ping ;)

On Sat, Mar 21, 2015 at 2:38 AM, Fedor Indutny <fedor_at_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, Jakub Hrozek <jhrozek_at_redhat.com> 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 {
>> > int age; /* generation of struct */
>> > void *member; /* always present */
>> > }
>> >
>> > And c-ares would always set age to 0 in the first generation. A future
>> > extension of the struct would bump the age to 1 and extend the struct:
>> >
>> > struct larger_in_future {
>> > int age; /* generation of struct */
>> > void *member; /* always present */
>> >
>> > /* only present if 'age' is >= 1 */
>> > void *later;
>> > }
>> >
>> > It means a program has to check age before accessing struct fields below
>> > 'member' which is a bit of an annoyance, but possibly doable as the
>> bumping
>> > shouldn't happen terrible often?
>>
>> I don't have a problem with that personally. It's a neat trick I haven't
>> used before.
>>
>
>
Received on 2015-04-06