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: Wed, 27 May 2015 21:24:35 +0200

Ping? ;)

On Mon, Apr 6, 2015 at 11:41 PM, Fedor Indutny <fedor_at_indutny.com> wrote:

> 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-05-27